Bill, I'm guessing that User is part of the inheritance tree that you switched from Vertical to Single Table. Is 5926 a valid primary key?
Ken On Sep 23, 2010, at 5:08 PM, William Hatch wrote: > Inherited a project where a few entities had been implementing vertical > inheritance. Part of the rework was moving from openbase to postrges, and > doing some additional cleanup. > > Anyway, after migrating all the data, and without changing the inheritance > modeling at all, I was getting this error: > > The object with globalID _EOIntegralKeyGlobalID[User (java.lang.Integer)5926] > could not be found in the database. This could be result of a referential > integrity problem with the database. An empty fault could not be created > because the object's class could not be determined (e.g. the GID is temporary > or it is for an abstract entity). > > At first I thought I may have done something wrong when resetting the pk > sequences in postgres after the migration, and given that we were using > vertical inheritance, with four different tables, it was likely that may have > been causing some issues. So I created a new single table, consolidated all > the original four tables into the new table, and then changed the table of > the base abstract entity to point to the new all in one table. Still got the > same error. I'm still glad I did it though; I didn't see any possible reason > for using vertical save for having to relax a few existing constraints that I > could handle at the app layer. I am able to CRUD on all the existing EO's > that are part of the old vertical design, after moving to the single table > model. But there's one area that is failing, where the above exception is > coming from. I've got: > > Invoices ->> Products > > Invoices -> Users (base abstract entity of the inheritance model) mandatory > not null, and delete rule is nullify > > Products -> Invoice > > > and we're blowing up when setting a product onto the invoice. > > Am I right in thinking that maybe I want to change the relationship from > Invoices to Users to be Invoices -> Clients, and make it optional in the > model? A potentially large wrinkle with that is that another of the inherited > entities also has a relationship to Invoices, and Invoices to it, also > pointing to the abstract User entity. Pointers or suggestions? Thanks. > > Bill > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
