Re: wrong column name with eo and relationships
Re: wrong column name with eo and relationships
- Subject: Re: wrong column name with eo and relationships
- From: John Larson <email@hidden>
- Date: Tue, 18 Jul 2006 12:27:35 -0500
Since I originally posted this, I redid the entire model and db to
use horizontal inheritance (which is actually better for the
application's purposes anyhow). The problem du jour is that the to-
many relationships that have the abstract parent class as the
destination don't fire their faults when the storedValueForKey is
called against them. Specifically
invoice -- toLines -->> (entity: invoiceLine)
invoiceFreightLine extends invoiceLine
invoiceCommentLine extends invoiceLine
etc.
Calls to invoice.toLines() return null (not an empty NSArray).
Further, there are no calls to the subclass tables showing in the sql
log.
I checked the db and it is fine. I don't know how wo would know if
it wasn't anyhow since it's not trying to get the lines! There are
no errors reported during the call toLines(). It is just that the
result is null, which then creates errors.
I read an issue that the java class for invoiceLine cannot be
abstract even if the entity is. So I changed that, but it made no
difference.
Any help would be appreciated.
John
On Jul 15, 2006, at 8:28 AM, John Larson wrote:
I just got done with a wholesale change to a model where I made a
table abstract and implemented vertical inheritance in subclassed
tables. That part seems to have gone fine. The problem is that
the parent class (the abstract class) is the destination entity in
a to-many relationship from another table (i.e., an invoice and its
lines). When I add an element to the to-many relationship using
addObjectToBothSidesOfRelationshipWithKey, the number that
corresponds to the source entity's pk ended up in a different
column?? So I took out the relationship altogether and rebuilt
it. Then it stopped putting it in wrong column, and a value from a
different relationship with the parent as the source ended up in
the same column?!
To paraphrase, the behavior is exactly like the to-many
relationship is joined to the wrong field, but it isn't in
eomodeler. As for as the eoeditingcontext is concerned, everything
is ok because the object is showing up fine on the screen. It's
just that instead of putting the invoiceid in the field called
invoiceid, it started putting it in the field "amount." I could
change the amount in the app and have it take it, so that was
something. And the change went all the way through to sql. When I
redid the relationship from scratch, it started putting the
destination key of a to-one relationship from the parent entity
into the "amount" field instead of the "accountID" field.
I'm using eomodeler and I poked around in the parent entity's plist
file and found _clientclasspropertynames that were from the old
implementation (before I restructured it). So I got to the point
where I just deleted them from the plist file. Then went back into
eomodeler and did nothing but save the file. They appeared again.
Not that those really matter, but it made me think that there may
be a hidden plist file somewhere that isn't getting cleared out.
So i cleaned, cleaned, and cleaned again in XCode to try to clean
everything out. I even rebuilt the Java file for the parent entity
for fun with no help.
I'm totally frustrated since everything looks like it is as fine as
good be expected in eomodeler. It is like when setting the sides
of the relationship it isn't setting the fields it has to by field
name, but by index, and that index is an invalid cached value. I'm
basically to the point where I would proceed with deleting all the
entities and rebuilding them from scratch, but I wanted to bounce
it off the group first.
Thanks,
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
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