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 can see that there is a "CascadeDeletes" property that you can set on the Context, but what about cascading update? |
|
|
|
|
Can you elaborate on what you are trying to achieve? If you cascade a change down a hierarchy of entities in your application code then all of those entities will be picked up when you call SaveChanges(). You can hook into the property change events to detect when a change occurs which would allow you to manage the cascading of any changes required if you want to do this in response to an entity being updated. Does that cover what you are after?
|
|
|
|
|
Well, I'm not sure if it's even smart to do what I as thinking this did anyway. I was thinking that the "CascadeDeletes" set the DeleteAction to Cascade in the db, but it doesn't. I was looking for the corresponding update cascade, but since the delete cascade didn't do what I thought it did I guess I'm asking a new question. Here goes. So is there a way to specify that I want a SQL Server db table record delete action to cascade in a relationship using LightSpeed? Would I even want to do that based on how LightSpeed's object graph works? If I can and if it's an ok idea, can I also do the same for the update action? |
|
|
|
|
No there isn't a way to specify this. From LightSpeeds perspective it expects to handle these changes directly in the in-memory entity graph. You certainly could implement this manually youself and it should work fine (although you may end up deleting an entity while it is still active in a running UnitOfWork so you would need to handle that situation yourself) but you could just use LightSpeeds native cascade to achieve the same thing. LightSpeed will automatically manage the wire-up between entities in associations (e.g. if you delete an entity it will automatically update all referring entities to unwire that association, or if you update an entity in an association it will update the corresponding FK value on any referring entity) so this usually covers the main reason you might want to use a cascade on update. You can also use the property change events to respond to an arbitrary change in an entity and then perform additional logic such as updating aggregates on parent entities or changing values on children as required and LightSpeed will track those changes as it does for all entities loaded into the UnitOfWork. There is some more detail in the docs about this which you can read online at: http://www.mindscapehq.com/documentation/lightspeed/Basic-Operations/Creating-Modifying-and-Deleting-Entities Does that help explain how the cascading works?
|
|
|
|
