Hi Bill, That error simply means that a foreign key (5926) in a table can't be found in the primary key of the related table (User), but since you don't have a true foreign key constraint in the database, it is left to EOF to stumble across it.
I'd look in your invoice table for a record that has 5926 as the User ID value. The first thing I'd do is add foreign key constraints to the database. They keep other non-EOF things honest. Dave Sent from my iPad On Sep 23, 2010, at 5:08 PM, William Hatch <[email protected]> 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/webobjects%40avendasora.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]
