databaseFailedToFetchObject and missingGlobalIDs: mystery solved
databaseFailedToFetchObject and missingGlobalIDs: mystery solved
- Subject: databaseFailedToFetchObject and missingGlobalIDs: mystery solved
- From: email@hidden
- Date: Mon, 29 Sep 2003 17:18:15 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
At some point in the past, I for some reason had the idea that the
EODatabaseContext.Delegate.databaseFailedToFetchObject method could be
used to throw an immediate exception when a fault is resolved, and the
row it references does not exist.
I'm not sure how I got this idea. None of the API documentation for
EODatabaseContext.Delegate actually says this. And I checked the old
versions of the docs too. However, actually, the CURRENT EOF book does
say this, at:
http://developer.apple.com/documentation/WebObjects/Enterprise_Objects/Fetching/chapter_6_section_10.html
It says "Invoked when a to-one fault cannot find its data in the
database. Use this method to immediately throw an exception."
However, if you look at the actual documentation for this method (which
has been made more clear in 5.2 than in previous versions), it's clear
that whether you return true or false, no exception will be automatically
thrown. If you want to throw an exception YOURSELF, you've got to do that
(and return false!). But at some time in the past, I erroneously
implemented this method to always return true, thinking that it would
cause an exception to be thrown. An exception never was thrown, but I
figured that was a bug, and forgot about it, leaving my method
implementation there.
But attention to the actual documentation of this method reveals that if
you return true, the globalID in question will NOT be added to the
missingGlobalIDs list, and in fact a snapshot will be created for that
row. And, presumably, you could even save this snapshot, and save the
previously missing row back to the db, although I haven't tried that. So
what I thought was causing more strict handling of missing globalIDs in
fact turned out to be causing incredibly leniant handling (too leniant
unless you actually are doing something useful in the delgate method
implementation!).
This is why I wasn't getting any globalIDs in the missingGlobalIDs list.
So beware! The databaseFailedToFetchObject method DOES do exactly what
the 5.2 API documentation for that method says it will do. Returning
'true' means "pretend this row DID exist", it doens't mean "throw an
exception." If you want to throw an exception, you can throw a
RuntimeException of some type yourself.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.