Re: horizontal inheritance oddity
Re: horizontal inheritance oddity
- Subject: Re: horizontal inheritance oddity
- From: Mike Schrag <email@hidden>
- Date: Thu, 25 May 2006 12:46:31 -0400
Yeah, actually, I am surprised I haven't seen more problems as
well ... This particular framework is only deployed as part of an
internal app, so it's not under that much load. Glad I noticed this
now :)
I use Wonder's connection dictionary updater, which changes
connection dictionary info based on Properties settings for each
model, but it appears to preserve everything else and just overwrite
the values specified (so I replace URL, name, and pw, but the rest
would be brought over from the original).
I'm going to add a flag to PW so it will optionally remove jdbc2Info
also ... Thanks for the suggestion.
ms
On May 25, 2006, at 12:04 PM, Chuck Hill wrote:
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