Anthony Paras wrote:
> >From the Tech Docs:
>
> <...If a snapshot already exists with the same primary keys, EOF will
> completely ignore the fetched row and just use the previous snapshot.
> This appears to be undesirable since the new fetch might have updated
> data. However, if the default was to always update the objects to the
> latest fetched data, your objects might be updated at unknown and
> invalid times. ...>
> You are doing a fetch from the database -- I can't imagine a better time
> to update changed objects. Why not set the default behavior to check
> for changed snapshots and update EOFs accordingly? ...
Hello,
Im just trying very hard to understand the concept behind this behaviour as
well. Im not implementing an app at this time, but still in the phase of
theoretical approach to WO, reading the EOF Developers Guide 3.51. I dont
think about the behaviour as bad, I just dont understand the priorities
chosen in this case.
Let me explain what Ive catched until now. My question is, whether the
impact on application design I see matches the experience of the more
advanced of you.
Todd Blanchards reply to Anthony contains this consideration:
> There are also implications wrt trashing user edits that can get hairy.
Another aspect of the design decision in question is the view from the
database: The Fathers of WO call it "optimistic locking".
I think, it has also to do something with the connection of EOF to its
front end at client side over the htt-protocol in comparison to the
situation in the LAN or on a single machine with an AppKit front end.
There might be other apps connected to the database at the same time. If
EOF would lock every piece of data it fetches, actually anyone else could
work on the database, not even reading data (because of EObjects
representing the actual state of an Object/entity from EOFs point of view,
not the database rows). This is the reason for "optimistic locking", which
means releasing the data immediatetly after fetching it/taking the
snapshot. Am I right with this ?
So what happens if a WOUser wants to update some data? EOF knows about
connection state, but isnt actually connected, as http doesnt support that
feature (this is the difference to an AppKit app). The request-Response
loop is triggered by user action, not by EOF (e.g. because of data being
refetched from the database, reflecting a difference to the previous
snapshot).
If EOF would send a page with the updated content without a preceeding user
request, the user could just have sent its entry at the same time, or the
browser window could be closed meanwhile. This might be the "unknown and
invalid time" mentioned in tech docs, in the first case even corrupting
session state inside WO as well. Bad solution.
Second try: The user requests data, changes it and hits the submit button.
The corresponding EObject is changed. EOF tries to update the row in the
database (and locks it for that reason), but finds out that it has changed
since the snapshot. At this point, does it depend from WO/EOF-programming,
whether the EObject changes are commited to the database regardless of the
fact, that the row has changed meanwhile? Does EOF release data, leaving
tht DB untouched, staying out of sync with it?
Is it the programmers responsibility to react? E.g. sending a page to the
WOUser telling: Sorry. The request could not be performed. Data has changed
meanwhile. It looks like that now: (showing fresh data). Try again?
(Button, that displays the submit page again with the former WOUser data
reentered).
Again Anthony Paras:
> From the Tech Docs:
> <...The snapshots associated with an EOEditingContext is never
> automatically released, even when the EOEditingContext is deallocated.
May it be released manually at least?
> This means that as data is fetched from the database, the number of
> snapshots, and hence your memory usage, will grow until you pull the
> whole database into memory.
Might be some Gigs? Havent got that memory in most cases. Inacceptable
behaviour. A kind of global commit required, depending on certain
conditions.
> This is a known problem with EOF that will be addressed in future
> releases....>
Which release is it, 3.51 as mine or 4?
>
> This is a direct result of mindset mentioned above. If you are not
> going to trust the database to provide objects as they're needed, then
> you have to keep every object you ever fetched -- in effect duplicating
> the role of the database.
>not going to trust<: I dont think like you, Anthony, see above, but:
>in effect duplicating (the role of) the database.<
I agree, a spectacular result and not very desirable.
Finally concluding my questions: Is this description of what is going on
technically correct? Are there better or simpler solutions then the one
suggested (returning an error page, possibly enriched with a retry button
as a convenience feature)?
Thanks, Christian
