This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Three questions: 1) Is there any special trick to getting cascade deletes to work for one-to-one associations? It works well for one-to-many associations but the one-to-one associations seem to be ignored - even when I manually introduce the dependent attribute on the parent's field. 2) Some postings indicate that if an association is non-nullable, then deletes will be cascaded. Others indicate that the association must be marked as dependent (see below 2 examples) for this to occur. Which is the correct advice? http://www.mindscape.co.nz/forums/Thread.aspx?PostID=5688 http://www.mindscape.co.nz/forums/Thread.aspx?PostID=5014 3) If the dependent attribute is required for this, the designer doesn't appear to support it for 1-to-1 relationships. |
|
|
It looks like one-to-one associations don't currently participate in cascade deletes. I'm going to ask somebody who knows this part of the code better than I to confirm this and see if we can add one-to-one support, but I'm not sure how quickly he'll be able to get round to it. Regarding your second question: Deletes will be cascaded if the association is non-nullable OR the DependentAttribute is set. (So Dependent is required only if you have a nullable association, but you want deletes to cascade rather than detaching.) Sorry for any confusion. |
|
|
Hi Aaron, One to One associations are actually handled for cascade deletes, but only if you are deleting from the "primary end". To explain that better, lets go back to how LightSpeed identifies a one to one association based on a database schema. If we have two entities, Yin and Yang, where Yin has a non nullable YangId and Yang has an nullable YinId then this would be set up as a one to one relationship with the Yang as the "primary end". e.g. If we delete the Yang, the associated Yin has to be deleted to avoid a database constraint violation. The reverse of this is not true however, if we deleted the Yin, it would be null'ed out on the Yang. When this gets translated into a LightSpeed model you will notice Yin has a YangId, but Yang only has an EntityHolder reference to a Yin. I suspect you are seeing the current behavior because you are deleting from the foreign end (e.g. the Yin above), in which case the entity can just be deleted in isolation. Deleting from the primary end (e.g. the Yang above) will cascade down to the Yin and you would notice that it selects out all Yins which have a YangId of the entity as it would for a normal one to many scenario. If you think this is not the case, would you be able to package up a small repro of this and send it through to jeremy at the obvious domain name and I can have a look at this. |
|