Re: PersistentObject relation handling design document
Frederik Holljen <fh@...
2006-09-08 08:12:57 GMT
Ho ho, =)
> >>> I have one question about the pre loading of objects. If you preload an
> >>> object and someone fetches it. What are you going to serve the next
> >>> person who requests that same object? Since we don't have any automatic
> >>> dirty checking you can not know if that object has been changed or not.
> >>> An alternative is to give him/er access to the very same object. In the
> >>> case on on demand loading are you going to store the loaded objects as
> >>> well so you can return them if it is requested again?
> >> I think we should not leave the problem of 2 people requesting the same
> >> object to PersistentObject, but to the application and offer a method to
> >> lock objects (on basis of the underlying database). I don't see, what
> >> this has to do with the problem of dirty-checking, though, could you
> >> elaborate a bit more, here?
> > These two are related because if session knows which objects are dirty
> > you can use this information to inform the user when he is requesting or
> > making changes to a second copy of the same object.
> Maybe we should speak in terms of requests here, not users. ;) That
> makes the situation a bit more clear.
Or within the same php process to be exact.
> So, if during 1 request a
> persistent object is fetched again, I think the session should actually
> return the already fetched instance. Refetching the object from the
> database is inaccurate, because it destroys already made changes. I
> think we do not need to inform the user that he fetches an object he
> already has. This allows us to use the persistent session as a kind of