Hi Kaspar, On Nov 4, 2010, at 5:08 AM, Kasper Frederiksen wrote:
> I have a referential integrity problem in my model and I am at a loss as to > how to debug this. > > To illustrate the problem in it's simplest form, I have made a model > containing two entities: User and Ticket. User has a ticket foreign key > (ticketFK) entity and a to-one relationship that maps User.ticketFK to a > Tiket primary key (ticketID). Can you switch this? Have Ticket.userFK as the relationship join? That would result in a user.tickets() relationship in EOF. > Tickets may become invalid, then this happens they are deleted. This will > typically happen in a separate editing context from the one containing the > User. To avoid users referencing a Ticket that does not exist I make a > relation from Ticket.ticketID to User.ticketFK and set the delete rule to > 'nullify'. > > There is no need for the business code to reference the user through the > ticket, so I do not mark the relation from Ticket to User as a class property. > > To test, I fetch a User and follow the relation to get the User's Ticket. > Then I localize this Ticket in to a new editing context, delete the local > Ticket and save the new editing context. I the database the ticket row is > gone. The User object still refers to the ticket -this can't be helped, it is > seeing cache. The problem is this: the User row in the database still has > ticketFK set! It is pointing to a Ticket row that does not exist. Saving the > Users editing context or termination the application does not change this. Using the modeling above will still leave you with the User referring to the deleted ticket unless you have a delete rule from Ticket to User. However this won't be in the database and won't "stick". > > Does some one have any suggestions as to how I debug why the 'nullify' rule > on the Ticket-->User relation does not work? > > Here are some of my further observations on the problem: > --- > No User update SQL is sent to the database, only the delete for the Ticket > row. > > I have tried changing the Ticket-->User relation to a class property. Since > the destination is not a primary key, WO now insists the relation be modeled > as to-many. I also write the getter and setter for the Users on the Ticket. > Now the above example works perfectly! The price I had to pay, is an > additional getter and setter in the business API. I would very much like to > avoid this since no business rule will ever need them and it is just > cluttering up the API. I think you can remove the methods, EOF will use KVC to get around not having them. > I am beginning to suspect that the model defined delete rules are only > triggered for relations that are also class properties. Can any one confirm > this? I think this is the case now. I think it was not the case in earlier versions, but I am not sure. Chuck > If any one wants to see the test code described above, I'll send you the > sample project. > > Kind regards, > -Kasper Frederiksen > > _______________________________________________ > 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/chill%40global-village.net > > This email sent to [email protected] -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
