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
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 usin
I'm using Sybase... but I'm pretty sure I'm using the regular JDBC
connector. Thanks for the hints!
Ken
On Feb 7, 2007, at 11:38 AM, Alexander Spohr wrote:
Hi,
What database are you using? I fixed that for PostgreSQLPlugin but
had no time so far to push it back to the svn.
if (bEntity.
Hi,
What database are you using? I fixed that for PostgreSQLPlugin but
had no time so far to push it back to the svn.
if (bEntity.isAbstractEntity())
{
NSArray anExternalNameArray = (NSArray) entity.subEntities
().valueForKey("externalName");
aBuffer.append(" (" + anExternalNameArray.compo
OK, so the only way I was able to solve this is that when a keypath
crosses an entity that's abstract and horizontal, I generate new
relationships on the entity the relationship is coming from - one for
each concrete subclass of the abstract entity, then generate an or
qualifier in its plac
Nope - all in the same model.
On Feb 6, 2007, at 12:20 PM, Mike Schrag wrote:
This is reaching a bit, but are your subclasses defined in another
model and maybe you're being bitten by the "my connection
dictionaries are exactly equal" thing? WEIRD side-effects happen
when that is the ca
This is reaching a bit, but are your subclasses defined in another
model and maybe you're being bitten by the "my connection
dictionaries are exactly equal" thing? WEIRD side-effects happen
when that is the case ...
uh ".. are exactly equal .."
ms
This is reaching a bit, but are your subclasses defined in another
model and maybe you're being bitten by the "my connection
dictionaries are exactly equal" thing? WEIRD side-effects happen
when that is the case ...
On Feb 6, 2007, at 12:05 PM, John Larson wrote:
Sounds like you're moving
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 ove
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 do
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
If you use eogen, check out the 6th template under my name on http://
en.wikibooks.org/wiki/Programming:WebObjects/EOF/Using_EOF/
EOGenerator ... I ran into this same thing a while back and grew
tired of having to remember this little nugget.
ms
On Feb 6, 2007, at 11:01 AM, Ken Anderson wrot
An excellent point Mike! I'll try it right now.
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
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
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
15 matches
Mail list logo
