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 noticed something unexpected when I was deleting an entity in my unit test, in that it appears Lightspeed is doing cascading deletes by default? I noticed it is issuing the necessary SQL to kill the related entities directly, which was actually a nice suprise because for Entity Framework and the others I have tested so far, I had to drop to direct SQL to do this since we are using MYISAM tables where this is not supported natively in the DB. I was going to turn it off when I first hit it, until I did some more digging and realized it means I think I can get rid of my direct SQL code now? And just delete the primary entity and all my related entities should get deleted also (and evicted from the Identity Map?). Is that correct? I assume this is specifically because cascading deletes are not supported with MYISAM tables, so the code is written to effectively do a software cascading delete in this case? What happens if I am using InnoDB tables, and this is set up in the database schema? Does Lightspeed simply evict the entities from the Identity Map, but not bother sending the SQL to delete releated entities since it knows the database is already doing it? |
|
|
As long as your model indicates that you have dependant entities and you leave Cascade Deletes on then LightSpeed will perform the deletes itself. It doesnt take into account what the database is going to be doing as this is left for you to control. From the docs (http://www.mindscapehq.com/documentation/lightspeed/Basic-Operations/Creating-Modifying-and-Deleting-Entities): "If an entity has dependent associations, LightSpeed cascade deletes the dependent entities. This avoids database integrity errors due to foreign key constraints. For example, if every Order is associated with a Customer, and you delete a Customer, then all Orders associated with that Customer are also deleted. However, if the association is not dependent – that is, if your model allows dangling Orders not associated with a Customer – then the Orders are merely detached from the Customer and remain in the database. You can override the default cascade delete behaviour by setting LightSpeedContext.CascadeDeletes in code or the cascadeDeletes attribute in configuration, or by setting the Cascade Deletes option on an entity (which affects all associations where that entity is the parent), or by setting the Is Dependent option on an individual association." Jeremy |
|
|
Seems to me that from a performance perspective, if the database schema indicates that it is already using cascading deletes for an association, that Lightspeed does not need to issue any SQL itself to implement this, and it would save quite a bit of SQL traffic? |
|
|
Yes absolutely, if you know the database is going to be doing that then you should turn off the cascade delete behavior within LightSpeed accordingly. We leave it up to you to make this determination as its not something we would detect for at runtime.
Jeremy |
|
|
That makes sense. For some reason whe I tried turning it off in the context it still tried to do the cascade? I thought setting it to off in the context would disable it for all entities? |
|
|
Ok, there is something really odd going on here. No matter what I do, lightspeed always wants to cascade delete my entities? I checked my model and it appears the default for associations is for the association to NOT be dependent, so it should not be doing cascading deletes. I have added the code to the XML for my model for a couple of associations and changed it to both true and false for isDependent, and no matter what I do it always tries to delete this one particular association. I am going to debug into the code right now to figure out what is going on, but shouldn't Lightspeed ignore the association if it is marked as NOT dependent (the default in the designer?). |
|
|
Ok, it turns out what is happening is that this is not related to cascading deletes at all, but rather related to the fact that Lightspeed is trying to break associations for associations where they are marked as nullable, even though the association is marked as non-dependent. I debugged through the code and realized that it way trying to execute this code when I delete an entity where I have nullable associations (basically where the foreign key is nullable): UPDATE So the only delete is actually for the entity itself, but it tries to break any associations to avoid dangling references. I assume if the associations are set to non-nullable, it would not do this and just leave them as dangling references? I would have expected it would only do this for dependent entities (although I suppose in that case it would actually issue casading deletes). Is there some reason Lightspeed always wants to do this? The reason this came up is because in our regression tests, we specifically have to load any related tables required to run the test, which helps us to make sure the code is not touching tables that are not related to the business logic in question. So now this particular unit test requires a ton more tables loaded due to the associations that are being broken. I can load those tables to make the tests pass, but I would like to better understand why the code is generated that way? |
|
|
Pretty sure there is a bug here, so I wrote up my finding in another post here: http://www.mindscapehq.com/forums/Post.aspx?ThreadID=4558&PostID=16128 |
|