Re: Dangling reference across non-ClassProperty relation
Re: Dangling reference across non-ClassProperty relation
- Subject: Re: Dangling reference across non-ClassProperty relation
- From: Chuck Hill <email@hidden>
- Date: Thu, 4 Nov 2010 09:45:17 -0700
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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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