Wow. Just wow. This might have been the nastiest thing (here
Nastiness is the SI unit that is equivalent to WTF's/hr) I've had to
track down in EOF that ended up having a surprisingly simple
explanation.
After literally hours of spelunking around in EOF and perusing
variables in the debugger, I tracked down the method where EOF was
just deciding to skip over primary key generation for my sub-entity.
Upon closer inspection, the /reason/ it was skipping PK generation
was that the EODatabaseContext instance for the sub-entity's model
was DIFFERENT than the EODatabaseContext instance of the SUPER-
entity's model. That's one of those "uh ..... what?" moments,
because they're pointing to the same database!
After more digging, there's this cute little method on EODatabase
"addModelIfCompatible" that decides whether or not a model should be
added to an existing EODatabase or whether a new EODatabase is
needed. This depends on EOAdaptor's canServiceModel model which
simply does model1.connectionDictionary().equals
(model2.connectionDictionary()). Well, wtf, I think, because they're
the same database. So I do this check myself. FALSE it says. So I
diff the dictionaries ... Hm. Everything is identical except ONE KEY/
VALUE PAIR. My super entity's DRIVER_VER (yes. DRIVER_VER. Hours of
time spent, remember) was "2.4.7" and the sub-entity's model was
DRIVER_VER "2.5.2".
As a result of this one key, connection dictionary equality is false
(nsdictionary's .equals method basically is true if all the key/value
pairs match between them), which causes each to exist in their own
EODatabase, which gives each a different EODatabaseContext, which
means that when the subclass goes to prepare for writing to the DB,
EOF decides that it should not generate a primary key for the entity
(why is this again? especially for horizontal inheritance, offhand I
think this is a bug, but that's a LITTLE bold -- I haven't had a
chance to think it through entirely), which means the insert just
doesn't have a PK in it. Explosion.
The moral? If you ever do cross-model inheritance, be damn sure your
connection dictionaries are EXACTLY equal. I'm tempted to add a
check into Project Wonder that if two models have the same URL and
User but the full connection dictionaries are not .equals=true, then
it should throw an exception by default. I suspect 99% of the time
this scenario is undesirable and will just result in strange problems
like I had the pleasure of enjoying.
ms
On May 24, 2006, at 6:37 PM, Chuck Hill wrote:
On May 23, 2006, at 7:45 PM, Mike Schrag wrote:
I have a model in a framework that defines Entity A and a model in
my project that depends on that framework that defines Entity B as
subclass of Entity A via Horizontal Inheritance. Entity A is
abstract (though the same problem occurs either way). When I run
my app, and create new Entity B's, the insert statements don't
include the primary key (resulting in an integrity constraint
violation). If i edit the model and simply remove the parent
entity reference from Entity B, and restart, everything works
perfectly. That fix is ACTUALLY is not that big of a deal from a
runtime perspective, except that I need the parent reference for
EOGenerator to work properly (basically I care more about the
inherited methods than I particularly care about it actually
having a relationship in the model). Anyone seen this one
before? It's been driving me crazy today -- I have to believe I'm
just overlooking something silly.
Are there any entities with a relationship to the parent that have
the relationship marked as Propogate Primary Key? If have seen this
cause the primary key to not get generated even the objects in
question were created but not related. I have been bitten by that
recently, and it was very hard to track down.
Another possibility is that something in the parent entitie's PK
definition is different and causing EOF to think that it can't /
shouldn't generate the PK.
Chuck
--
Coming in 2006 - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/
practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
