Re: modeling problem
Re: modeling problem
- Subject: Re: modeling problem
- From: Lachlan Deck <email@hidden>
- Date: Wed, 1 Apr 2009 07:54:00 +1100
On 31/03/2009, at 8:16 AM, Chuck Hill wrote:
On Mar 30, 2009, at 1:58 PM, TW wrote:
On Mar 30, 2009, at 1:18 PM, Chuck Hill wrote:
On Mar 29, 2009, at 4:48 PM, TW wrote:
I have a model of our ldap directory with InetOrgPerson the base
"user" entity. I've made InetOrgPerson abstract with it's table
inetOrgPerson. I have the framework project containing that model
in the build path of another that I'm using as a "generic user"
framework.
In that second framework I have another model with a
"GenericUser" entity. That entity has "InetOrgPerson" as it's
parent. I've added this second framework to my app build path.
- in Entity Modeler if I set the table for "GenericUser" to
"inetOrgPerson" (the same as it's parent), my app fetches 2
identical GenericUser EO's for each 1 matching record in LDAP
That is because you have set up Single Table Inheritance BUT not
added any restricting qualifier on either entity. Are you certain
that InetOrgPerson is marked as abstract? Check it again...
InetOrgPerson is definitely checked "Abstract" in my OD model.
I have never tried this without a restricting qualifier on one of
them.
You could try adding a restricting qualifier of (1 = 0) on
InetOrgPerson.
I didn't think I needed a restricting qualifier if the parent was
abstract. I do get errors requiring a restricting qualifier if
InetOrgPerson is _not_ abstract.
This sounds like a bug to me right now, please* bugreport.apple.com
That sounds right though. i.e., if you're fetching on the super entity
(with deep fetch being true) it needs to know how to distinguish
whether each record fetched is a parent node or not I would have
thought.
I'm trying to abstract everything so that I can pick and choose
what gets used on a per app basis.
- if I change the table for "GenericUser to "GenericUser" it
works as expected. However, there is no such "table" or object in
my LDAP directory. And I'm concerned that with that setup
attempts to write to the directory would fail.
It should be OK like that. That is Vertical Inheritance which may
have its own issues.
Well, I'm willing to tackle those issues when I encounter them if
this should work. Fetches are currently working if I leave it as is
and I'm not currently using any WO apps to create GenericUser or
InetOrgPerson EO's.
Careful, that VI stuff can be dodgy.
As it stands this is true with the stock frameworks - though the fixes
are easy for Apple to implement. Now, alas, there's a regression in
5.4 with VI too .. but I think it'll only get fixed in EOAccess when I
set up a test case with Apple's own inheritance example app and send
it back to them. Gotta love the irony here ;-)
Anyway, the bug is seen when you mark the parent as abstract but where
the parent has an external name that's not null and is uniquely
different from its child entity external names (i.e., VI). So with 5.4
it wrongly assumes that the parent entity has no corresponding
externalName when generating primary keys. So the EO_PK_SUPPORT table
gets populated with child entity names rather than the parent entity -
which leads to duplicate pk insert attempts at some point.
I've reported the issues with accompanying details on the lines of
code at fault. I've been able to fix the problem in my own subclasses.
I should supply my fixes to wonder I suppose. Patch to be submitted
when I'm off the train...
with regards,
--
Lachlan Deck
_______________________________________________
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