Anthony Paras <[EMAIL PROTECTED]> wrote:
[ 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.
It makes it harder for developers who are stuck in a particular
mindset. For those like myself who began developing with strong OO biases
and no SQL/traditional database biases, it was tremendously efficient and
simple!
[ >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?
I would agree, and I never liked NeXT's argument for having
refreshesRefetchedObjects defaulting to NO.
[ The
[ setRefreshesRefetchedObjects option is terribly inefficient as it causes
[ all snapshots (changed or not) to be updated.
There is a delegate method which you can override to implement your
own behaviour of comparing snapshots. I believe the method is on
EODatabaseContext.
[ <...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.
I'm not sure I would jump to this conclusion. I think there may be
more complications than this which led to this problem. Regardless, there
was a workaround posted by Craig Federighi to the EOF mailing list sometime
back. I'm not certain why it didn't make it into the 3.0 release. Anyone
from Apple care to comment?
Regards,
Paul
---
Paul Summermatter
LGS Systems, Inc.
Medical Computing Division
15 TJ Gamester Ave
Portsmouth, NH 03801-5871
(603) 433-9822 voice
(603) 433-9818 fax
(888) 898-6321 pager
[EMAIL PROTECTED] paging email
[EMAIL PROTECTED]
(NeXT or MIME Mail Welcome)
http://www.lgs-systems.com
