• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: wrong column name with eo and relationships
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wrong column name with eo and relationships


  • Subject: Re: wrong column name with eo and relationships
  • From: Chuck Hill <email@hidden>
  • Date: Tue, 18 Jul 2006 16:20:18 -0700

John,

Check the model, especially for the abstract entity to ensure that it is not missing any table or column names. That is a common source of this problem.

Chuck


On Jul 18, 2006, at 4:06 PM, John Larson wrote:

Thanks to both of you for your response.

I have double check and rechecked and I'm still having the same problem. I rebuilt the relationship to the abstract entity again to no avail. I have double checked for overridden methods that didn't call super. I believe that I was hasty in my previous conclusion, however, regarding what was happening. I stopped jumping around and looked at the stack trace:

File
Line#
Method
Package

EODatabaseChannel.java
769
_selectWithFetchSpecificationEditingContext
com.webobjects.eoaccess
EODatabaseChannel.java
805
_selectWithFetchSpecificationEditingContext
com.webobjects.eoaccess
EODatabaseChannel.java
215
selectObjectsWithFetchSpecification
com.webobjects.eoaccess
EODatabaseContext.java
3205
_objectsWithFetchSpecificationEditingContext
com.webobjects.eoaccess
EODatabaseContext.java
3346
objectsWithFetchSpecification
com.webobjects.eoaccess
EOObjectStoreCoordinator.java
539
objectsWithFetchSpecification
com.webobjects.eocontrol
EOEditingContext.java
4114
objectsWithFetchSpecification
com.webobjects.eocontrol
EODatabaseContext.java
4260
objectsForSourceGlobalID
com.webobjects.eoaccess
EOObjectStoreCoordinator.java
682
objectsForSourceGlobalID
com.webobjects.eocontrol
EOEditingContext.java
3965
objectsForSourceGlobalID
com.webobjects.eocontrol
EODatabaseContext.java
4427
_fireArrayFault
com.webobjects.eoaccess
EOAccessArrayFaultHandler.java
70
completeInitializationOfObject
com.webobjects.eoaccess
_EOCheapCopyMutableArray.java
38
willRead
com.webobjects.eocontrol
_EOCheapCopyMutableArray.java
92
count
com.webobjects.eocontrol
EOSortOrdering.java
173
_sortUsingKeyOrderArray
com.webobjects.eocontrol
EOSortOrdering.java
238
sortedArrayUsingKeyOrderArray
com.webobjects.eocontrol













I left off the code beforehand. So it appears as if eo is trying to get the array and the reason that I'm not seeing the fault resolution in sql is that nullPointerException isn't upon access of the retval (as I hastily concluded), but something else is null that I can't see. Looking in eomodeler, and looking at the plist files individually, I just can't see what is going on. As for not inserting them into the editing context, if I change the relationship I want to view to one of the subclasses, then everything works ok. I just don't see why when I call to the superclass I get this error. As soon as a call a subclass, it works ok (except the resulting nsarray doesn't have the other subclass objects). Obviously I've got something wrong somewhere.

I have removed the table name from the abstract entity, and marked it as abstract. I used the createSubclass menu item to try to prevent typos and didn't change anything it did. I checked all the columns to make sure there were column names. I checked the table name on the subclasses to make sure it was there. (Again, relationships to them work, so there can't be too much structurally wrong with them in and of themselves). I made all the abstract entities concrete in Java as per Apple's instruction. If I use the eo editor in XCode all the subclasses show up under the parent class in the hierarchy view, so I know i've set the parent right. I've even walked around my desk clockwise and counterclockwise, and still the same thing.
Thanks again,
John


On Jul 18, 2006, at 4:16 PM, Chuck Hill wrote:


On Jul 18, 2006, at 10:27 AM, John Larson wrote:

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.


Returning null is a symptom of having an awakeFromInsertion or awakeFromFetch method that does not call the super implementation. It could also mean the (new) object has not been inserted into an editing context. I'd check the class and see if you have overidden (even accidentally) one of the EOF methods and forgotten to call super.



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.

Try the above. As sort of a general guide to where to look, what you are describing sounds more like a bug in your Java code than in the model.


FWIW

Chuck


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:
@mac.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:
40global-village.net


This email sent to email@hidden

--
Coming sometime... - 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






--
Coming sometime... - 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
  • Follow-Ups:
    • Re: wrong column name with eo and relationships
      • From: John Larson <email@hidden>
References: 
 >wrong column name with eo and relationships (From: John Larson <email@hidden>)
 >Re: wrong column name with eo and relationships (From: John Larson <email@hidden>)
 >Re: wrong column name with eo and relationships (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Display group tutorial
  • Next by Date: Re: wrong column name with eo and relationships
  • Previous by thread: Re: wrong column name with eo and relationships
  • Next by thread: Re: wrong column name with eo and relationships
  • Index(es):
    • Date
    • Thread