Thanks David, Very weird; it worked in Openbase just fine with the missing record, which, sure enough was the problem. Now, this process that I was talking about only involves new objects, product, invoice and user in this case are all new. Must have been trying to get faulted in for some reason. Thanks again; very much appreciated.
Bill On Sep 23, 2010, at 5:37 PM, David Avendasora wrote: > 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]
