Re: Setting up horizontal inheritance

Subject: Re: Setting up horizontal inheritance
From: Paul Hoadley <email@hidden>
Date: Mon, 3 Nov 2008 17:00:17 +1030

On 03/11/2008, at 3:59 PM, Chuck Hill wrote:

On Nov 2, 2008, at 9:18 PM, Paul Hoadley wrote:

I'm sure I'm close to understanding this... thanks for bearing with me.

On 03/11/2008, at 1:19 PM, Ken Anderson wrote:

On Nov 1, 2008, at 10:51 PM, Paul Hoadley wrote:

I've implemented it using HI, and it seems to be working. I'm not convinced I have it quite right, though. There's another EO in the utility-framework's model, UserPreference. UserPreference has a to-one relationship with Person to denote the owner of the preference. In the particular app, though, I'm now using AMPersons, and hence the amperson table in the database---but UserPreference.person relationship obviously looks for a Person in the 'person' table, and there aren't any. To overcome this, I have sub-classed UserPreference to create AMUserPreference, with the only change being that the person relationship points to AMPerson. This seems inelegant to me---am I doing it right? (Or is this a candidate for the kind of dynamic model change you refer to above?)

This is why it would be better for Person to be abstract, and have different subentities for each application. That way, UserPreference could have a relationship to the abstract Person entity, which would automatically search all the subentities for the correct one for that particular primary key.

I've made Person abstract in the model. I've deleted the redundant EO (AMUserPreference), and UserPreference (which is in the same framework as Person) points to the abstract Person entity. I no longer generate a 'person' table, as I won't be instantiating Person.

That might be a bad idea. Some databases ( FrontBase) need this base table for PK generation.

I'm using Postgres, but I've reverted to generating the table anyway. I did notice that Entity Modeler is now generating SQL for an amperson_seq sequence as a result of making Person abstract.

Now, where the app would create a UserPreference, I get this on saving:

[2008-11-3 15:33:36 CST] <WorkerThread0> <com.webobjects.appserver._private.WOComponentRequestHandler>: Exception occurred while handling request:
java.lang.NullPointerException
Application.handleException: Handling an Exception:
java.lang.NullPointerException
at com.webobjects.eoaccess.EODatabaseContext._verifyNoChangesToReadonlyEntity(EODatabaseContext.java:4696)

That is often caused by having a FK marked as a class property. That is the first think that I would check.

I couldn't find anywhere I was doing that. Inexplicably, I had the PK marked as a class property in both Person and AMPerson, so I've fixed that.

I assume the "read only entity" is the newly-abstract Person. But I don't have any Person entities---I've made Person.java an abstract class.

I have some vague recollection that this can cause problems for EOF. It might only be in specific situations and I no longer recall any details. I have just avoided making abstract Java classes for EOs for years.

Reverted.

Now, all I need to do is touch an AMPerson, for example by logging in, and then on the next access to that table (for example, by logging out, and then back in again) I get this:

[2008-11-3 16:53:8 CST] <WorkerThread2> <com.webobjects.appserver._private.WOComponentRequestHandler>: Exception occurred while handling request:

java.lang.IllegalStateException: rowDiffsForAttributes: snapshot in com.webobjects.eoaccess.EODatabaseOperation {_dbSnapshot = {}; _entity = "AMPerson"; _newRow = {lastName = "Hoadley"; lastLogin = 2008-11-03 06:23:08 Etc/GMT; id = 1; username = "super"; dob = 1973-06-07 14:30:00 Etc/GMT; password = "hFG6ihTXl1PTTLM7UbpGtLAl64E="; firstName = "Paul"; lastPWChange = 2007-11-12 13:30:00 Etc/GMT; }; _object = "PERSON: Paul Hoadley"; _globalID = _EOIntegralKeyGlobalID[AMPerson (java.lang.Integer)1]; _databaseOperator = "EODatabaseUpdateOperator"; } does not contain value for attribute named contactDetailsID with snapshot key: contactDetailsID

Application.handleException: Handling an Exception:

at com.webobjects.eoaccess.EODatabaseOperation.rowDiffsForAttributes(EODatabaseOperation.java:344)

at com.webobjects.eoaccess.EODatabaseContext.createAdaptorOperationsForDatabaseOperationAttributes(EODatabaseContext.java:5192)

at com.webobjects.eoaccess.EODatabaseContext.createAdaptorOperationsForDatabaseOperation(EODatabaseContext.java:5369)

at com.webobjects.eoaccess.EODatabaseContext.performChanges(EODatabaseContext.java:6184)

at com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditingContext(EOObjectStoreCoordinator.java:376)

at com.webobjects.eocontrol.EOEditingContext.saveChanges(EOEditingContext.java:3176)

at net.logicsquad.am.Session.userLogin(Session.java:138)

at net.logicsquad.am.components.pages.LogIn.loginButtonAction(LogIn.java:54)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at com.webobjects.foundation.NSKeyValueCoding$ValueAccessor$1.methodValue(NSKeyValueCoding.java:636)

at com.webobjects.foundation.NSKeyValueCoding$_MethodBinding.valueInObject(NSKeyValueCoding.java:1134)

at com.webobjects.foundation.NSKeyValueCoding$DefaultImplementation.valueForKey(NSKeyValueCoding.java:1293)

at com.webobjects.appserver.WOComponent.valueForKey(WOComponent.java:1686)

at com.webobjects.foundation.NSKeyValueCoding$Utility.valueForKey(NSKeyValueCoding.java:447)

at com.webobjects.foundation.NSKeyValueCodingAdditions$DefaultImplementation.valueForKeyPath(NSKeyValueCodingAdditions.java:212)

at net.logicsquad.am.AMComponent.valueForKeyPath(AMComponent.java:153)

at com.webobjects.appserver._private.WOKeyValueAssociation.valueInComponent(WOKeyValueAssociation.java:50)

at com.webobjects.appserver._private.WOSubmitButton.invokeAction(WOSubmitButton.java:70)