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
|
I have a situation where I want to delete the parent, but I don't want lightspeed to generate queries for deleting the children of the parent, because as it turns out this could be inefficient if the children have children and so on, which the case in my data model. In addition, I know that the parent will only have a single child. Hence, there is no need for cascade delete. I suspect that this might be achieved by setting Dependent to False. I tried to set this on the parent's association but it wasn't working. Is there any way to do this and/or am I using the wrong approach?
|
|
|
There are two ways to do this: 1. Make the association nullable. This changes the behaviour of the child item slightly, in that it allows children to exist with no parent; this may or may not be acceptable depending on your model. Also, LightSpeed will still issue an UPDATE to set the parent of any child items to NULL (though this will not have ongoing multi-level cascade effects so the efficiency impact is minimal). 2. Use TableAttribute(CascadeDeletes=false) on the entity. However this will prevent cascade deletion on *all* associations from that entity. This is available in the designer via the Cascade Deletes setting on the entity. (You can also set LightSpeedContext.CascadeDeletes = false but that will prevent cascade deletion on all associations in the entire model.) The designer Dependent setting only has an effect when the association is nullable, in which case setting Dependent = true in this case forces cascade deletion (which normally doesn't happen for nullable associations). Setting Dependent has no effect in the non-nullable case. |
|
|
The first solution is not an option for me. I would be fine with the second one if it worked. I tried both the table attribute and the setting the CascadesDelete flag on the context. However, it doesn't seem to be working. It still queries for children. For instance:
BEGIN
Another thing that I don't understand is why does it query for ONSITE_SYSTEMS when there are no FACILITIES for that address? The database schema is like this: ADDRESS - FACILITY ( one-to-many) FACILITY - ONSITE SYSTEM (one-to-many?
|
|
|
CascadeDeletes=false prevents the DELETE query for the cascades. It still does a SELECT for the children's IDs in order to locate any in-memory children so that it can mark them as deleted. (This may be a bug, since the database entries are not going to be deleted; I'll raise it with someone who knows this part of LightSpeed better than I do!) The query for grandchildren when there are no children is probably something we can optimise out, but again, I'm going to need to pass this on to someone who understands that part of the code better than I do. Thanks for drawing our attention to this. |
|
|
The grandchildren query can definitely be optimized out when there are no children, and the child query also seems unneccesary in this scenario. We will need to build up some better tests around these scenarios before we commit a fix, but I will look to get on to this next week and will post back once we have something in a nightly build for you to grab :) |
|
|
Thanks for checking this out. This can be a real issue when you have a hiearchical data model. I can understand the need for a query for the children to a certain degree, but definitely the query for grandchildren shouldn't be executed if there are no children. |
|
|
No problem, we have committed a set of fixes tonight for these two scenarios and they will be available in the next nightly build (20090702) and later. If you can let us know how these look for your scenarios that would be much appreciated in case we need to add any additional test cases here. |
|