Re: Deleting with Referential Integrities
Re: Deleting with Referential Integrities
- Subject: Re: Deleting with Referential Integrities
- From: Florijan Stamenkovic <email@hidden>
- Date: Tue, 28 Jun 2005 13:08:13 +0200
On Jun 28, 2005, at 01:35, Greg wrote:
Album has a to-One relationship to image via the icon relationship. It
has a to-Many relationship via the images relationship. Image does not
have an inverse relationship for icon, but does for images (album).
Icon is optional with a delete rule of nullify, images is optional
with a delete rule of cascade and owns destination. The inverse
relationship album in Image is mandatory with a delete rule of no
action.
So:
1. Rel called Icon: Album > Image (optional, nullify)
2. Inverse to Icon: Image >> Albums (not existing)
3. Rel called Images Album >> Image (cascade, owns destination)
4. Inverse Images Image > Album (mandatory, no action)
Difficult construction I think. OK, the owns destination part in the
Images relationships (Album>>Image) implies that THERE CAN BE NO IMAGE
RECORD THAT IS NOT A PART OF THE ALBUM. This implies that the icon for
the album also must be a part of the album as an image. Is that
correct???
What you could do is:
Foreign Keys:
Album:
1. IconID (can be null)
Image:
1. AlbumID (can be null)
Relationships:
Album:
1. Icon ( Album>Image, over the IconID in Album) - optional, and if
an icon can not be a part of the album as well, set to cascade,
otherwise to nullify
2. Images ( Album>>Image, over the AlbumID in Image) - optional, if
an image can be an icon as well, set to nullify. Otherwise set to
cascade
This is fine for a construction where an icon is not a part of
Images, and is a icon for only one album. Then you set both to cascade.
Image:
1. Album (Image>Album over AlbumID in Image) - optional, delete rule
set to nullify
2. AlbumsForIcon (Image>>Album over IconID in Album) - optional, set
to nullify. It is a to many relationship because the construction is
such that you can not use a to-one
As you can see this is very loose, so you should be checking things
programatically (if there is no icon for an album, then you can not
save). If you have two different kinds of relationships relating two
tables will make it quite difficult (if not impossible) to set
integrity options properly. And I would suggest using
addObjectToBothSidesOfRelatinshipWithKey() and
removeObjectFromBothSidesOfRelationshipWithKey() methods instead of
setter methods when relating objects.
A better approach for this in my eyes is subclassing using single table
inheritance. Check Apple docs on what to do. In fact I think it is a
situation almost designed to use that system. This however would imply
that the same Image record can not be a part of an album and an Icon at
the same time. You would have to store it twice.
Or if you want to make it even easier for yourself, just use two
different tables. Again implying that you have either Image or Icon
records.
All is depending of what your custom manipulation ideas are... Hope you
can make something out of all this :)
Flor
_______________________________________________
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