Dangling reference across non-ClassProperty relation
Dangling reference across non-ClassProperty relation
- Subject: Dangling reference across non-ClassProperty relation
- From: Kasper Frederiksen <email@hidden>
- Date: Thu, 4 Nov 2010 13:08:41 +0100
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).
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.
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 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?
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden