As someone who has implemented O-R mapping systems before - this is
a simple efficiency issue. The goal is to guarantee no more than one
representation of a given object in memory at any one time. Its
most efficient when doing a fetch to just check that the object
corresponding to a given primary key exists and substitute that
object in the result collection if it does.
Comparing all the values to see whats changed or simply overwriting
all the values all the time is more expensive - a lot more expensive.
There are also implications wrt trashing user edits that can get
hairy.
> From: Anthony Paras <[EMAIL PROTECTED]>
> Date: 1999-03-16 09:35:51 -0800
> To: Multiple recipients of list <[EMAIL PROTECTED]>
> Subject: EOF Egotism (or EOF needs to defer to database
representation of
> X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas
> Originator: [EMAIL PROTECTED]
> X-Comment: To unsubscribe, follow directions at
> http://www.omnigroup.com/MailArchive/
> X-Mailer: Mozilla 4.5 [en] (WinNT; U)
>
> Default EOF behavior seems to assume that EOF objects are more valid
> than those represented in the database. This attitude leads to
> confusion for developers and makes the product harder to implement
> efficiently.
>
> >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? The
> setRefreshesRefetchedObjects option is terribly inefficient as it
causes
> all snapshots (changed or not) to be updated.
>
> <...The snapshots associated with an EOEditingContext is never
> automatically released, even when the EOEditingContext is deallocated.
> 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.
> This is a known problem with EOF that will be addressed in future
> releases....>
>
> 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.
>
>
>
