Re: horizontal inheritance oddity
Re: horizontal inheritance oddity
- Subject: Re: horizontal inheritance oddity
- From: Chuck Hill <email@hidden>
- Date: Thu, 25 May 2006 09:04:00 -0700
I am surprised that this is the only problem that his caused! What
do you use to connect the models at application startup? Our class
replaces the entire connection dictionary to ensure that this sort of
thing does not happen.
Another moral of this story is that having jdbc2info in the
connection dictionary can save a small amount of time at application
startup and avoid a second database connection, but when things go
wrong with it, debugging is tough. I remove this as a matter of course.
Chuck
On May 24, 2006, at 9:55 PM, Mike Schrag wrote:
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden