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 general concept question: I try to work with short lifespans of unit of work, meaning I read data (lists and structures) into memory and work directly on the entities but with the original unit of work disposed, because there is user interaction (editing fields and also structures using diagram) which could last a long time. Now when I update the modifications I reread the entities into another unit of work. Currently I use reflection to update the fields for all entities marked as Modified (or New and Deleted respectively). This makes it generic and I do not have to worry about entity specific code. I am not sure if there is another way. I handle differences and conflicts in this "save routine" if the ChangedOn timestamps between the original and newly read entity is different (another user may have changed something - and I do not lock ). My question part 1: Can I relink an original entity from a disposed uow to a new uow replacing the corresponding object/record Question Part2: If there is a mechanism, does lightspeed check timestamps for possible changes against the original ? What is the general consideration for lifespan of uow ? I only keep it alive while I am retrieving/filtering data. Once the read is finished I dispose uow and reread for updates, deletes or inserts. regards gmd |
|
|
|
|
re 1: We do provide the UnitOfWork.Attach and UnitOfWork.Import to handle this. Import is primarily designed for use with POCO's but its also fine to use with disconnected entities and it does not handle traversing any associations though so if you are already covering this off in your custom mapper then you might prefer to stick with that. re 2: No we dont check any of the timestamp columns for concurrency checking, we use the LockVersion field as our baked in approach for optimistic concurrency control. So again you may want to switch over to this as it will mean LightSpeed will take care of the checks for you, or you can stick with your custom approach if you prefer to use the timestamp columns for control and not have to add the additional LockVersion column. See http://www.mindscapehq.com/documentation/lightspeed/Implementing-Storage-Policies-with-LightSpeed/Concurrent-Editing for details about LockVersion. Generally we advocate for short lived UnitOfWork instances so generally we would suggest detaching entities that are going to exist longer than the UnitOfWork scope and then attaching them back into any new UnitOfWork where they need to be enlisted.
|
|
|
|
|
Thank you Jeremey. regards gmd |
|
|
|
