John,
I *have* solved this problem, albeit slightly inelegantly. I
determine when such a situation exists, create duplicate
relationships to all the concrete sub-entities, and create an OR
qualifier to replace the key value qualifier. At the moment, my
implementation requires a subclass of EOEditingContext and the
qualifiers, but it doesn't have to be that way. Let me know and I'll
be happy to split out the code for you.
Ken
On Feb 10, 2007, at 7:42 AM, John Larson wrote:
Son of a gun, I tried it on a identical situation in my model and I
got the same thing! I also use the regular jdbc driver. I've never
had to do it before so I never caught it. So, if misery loves
company, at least you now have company.
I would definitely say that eo does not support using relationships
defined in abstract entities that are subclassed using horizontal
inheritance as query qualifiers. Another one of those things to
put in the "just when you think you understand eo . . . " file.
(See my post about batch faulting relationships from abstract
entities when using single table inheritance.)
John
On Feb 6, 2007, at 11:13 AM, Ken Anderson wrote:
John,
The concrete sub-entities are not abstract - and yes, I've been
bitten by that EOModeler 'feature' too.
Unfortunately, I found another case where it's difficult to work
around it... so I'm still stuck trying to figure this out. I have
a feeling that I'm going to have to iterate over all the child
entities and perform this query separately on each individual
concrete sub-entity. Not optimal, but not too bad either
considering the alternative I was using, which is to fetch all the
objects and qualify in-memory (yikes).
The database is multi-company, and I have to be very strict to
make sure data from one company doesn't co-mingle with another.
To do that without duplicating the company OID in each table, I
have a userInfo attribute called 'MemberCompanyRoleKeyPath'. I
then qualify on whatever that keypath is so that all records for a
particular company can be found.
Thanks for your thoughts!
Ken
On Feb 6, 2007, at 12:05 PM, John Larson wrote:
Sounds like you're moving on already, but I want to remember
having this problem before when using EOModeler. Creating
subclasses of abstract entities defaults the subclasses to
abstract. Are you sure your subclasses are not abstract? I use
horizontal inheritance all the time for some documents with
different line types that are vastly different. Can you qualify
on an attribute that isn't a relationship?
John
On Feb 6, 2007, at 10:31 AM, Ken Anderson wrote:
Unfortunately, that didn't work. Even with setIsDeep set to
true, it still has NULL for the table name. And yes, the
abstract entity is set to abstract.
Oh well - I'm going to go with single table for this particular
situation.
Thanks again Mike.
Ken
On Feb 6, 2007, at 10:58 AM, Mike Schrag wrote:
If I had to guess, I bet it's because none of the EOUtilities
methods do a fetchSpec.setIsDeep(true) and thus don't fetch on
subclasses. If you steal the code from that method and add the
setIsDeep, maybe that will work?
EOQualifier qualifier =
EOQualifier.qualifierWithQualifierFormat(format, args);
EOFetchSpecification fetchSpec = new EOFetchSpecification
(entityName, qualifier, null);
fetchSpec.setIsDeep(true);
NSArray results = ec.objectsWithFetchSpecification(fetchSpec);
On Feb 6, 2007, at 10:54 AM, Ken Anderson wrote:
Everyone,
I swear this has worked in the past - if I'm mistaken, please
remind me!
I have an entity (MemberRuleField) with a relationship to an
abstract entity (MemberRule). MemberRule (and it's sub-
entities) has a relationship called MemberCompanyRole (this
defines what company the rule is for). The inheritance
structure is implemented using horizontal inheritance
(separate table for each concrete sub-entity).
I would like to perform this query:
eos = EOUtilities.objectsWithQualifierFormat(ec,
"MemberRuleField", "memberRule.memberCompanyRole = %@", new
NSArray(new Object[] {memberCompanyRole}));
What I think this should do is create a query for every
concrete sub-entity. Instead, I get this:
SELECT t0.field_values, t0.long_field_values,
t0.member_rule_oid, t0.oid, t0.op, t0.rule_field_oid,
t0.trans_id FROM member_rule_field t0, null T1 WHERE
T1.member_company_role_oid = ? AND t0.member_rule_oid =
T1.oid" withBindings: 1:11(memberCompanyRoleOid)>
I only get one query, and the table name is NULL for the
related table. That unfortunately makes sense, because the
memberRule relationship points to the MemberRule entity, which
is abstract and does not have a table (yes I know, single
table inheritance would solve this problem...and vertical
would probably solve it too).
Any thoughts? I would really prefer to use horizontal here...
Ken
_______________________________________________
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/mschrag%
40mdimension.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/lists%
40anderhome.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/the_larsons
%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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/lists%
40anderhome.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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
