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
|