Why is all properties updated?

Hi! Lets say I have a simple Person class, with an ValueObject for Address, all generated from database using the designer for Lightspeed. 1. I Create a person 2. I Create a UnitOfWork 3. I Add the person 4. I update the Lastname 5. I call SaveChanges on the same UnitOfWork The sql that is generated sends all properties, even the once that hasn't changed. WHY? //Daniel

Hi Daniel,

This is a limitation of LightSpeed currently. It does have the benefit of ensuring concurrency however we have already improved this with LightSpeed 3.0 where partial updates will be available if using a lock field on your table (again, concurrency is a focus).

I hope that helps,

John-Daniel Trask

Hi! Ok. Thanks for your reply. Have you implemented component mapping? //Daniel

[quote user="John-Daniel"]however we have already improved this with LightSpeed 3.0 where partial updates will be available if using a lock field on your table (again, concurrency is a focus).[/quote] 

Could you maybe give little more details regarding this?

Are you saying that for partial updates row-version columns will be a must?
I.e. if I modify column3 and column4 the generated sql will be:
update sampleTable
set column3 = @newValue3
,     column4 = @newValue4
where id = @id
and rowversion = @oldRowversion
?

Will you be having an option (or considering it) of having the generated update without rowversion, into something like this:
update sampleTable
set column3 = @newValue3
,     column4 = @newValue4
where id = @id
and column3 = @oldValue3
and column4 = @oldValue4
?

Just to get more idea why the above question, we're in the middle of developing new system with Lightspeed 3.0 in mind. And regarding database table design, the answer makes some difference - will all tables need an extra rowversion column.

Do you expect with Lightspeed 3.0 to support optimistic concurrency only if there is a lockversion column?
Or will partial updates also give concurrency detection, with the generated SQL like in the previous post?

Just updating this - you will require a lock field for updates with LightSpeed 3.0.

The reason we aren't going to add support for simply comparing the original values is because we do not believe this is safe when developing rich domain models - something we advocate and is one of the core focuses of LightSpeed. Richer validation can become an issue and we want to avoid loading an entity that is invalid immediately. This is one of the primary drivers behind the decision.

The second reason is that while we are looking to add field level change tracking within LightSpeed 3.0, the storing of original values will be an option to enable / disable (disabled by default). Storing the original values, especially for large fields, chews up memory and bloats objects up - we want to avoid that unless absolutely required.

Consider this scenario:

An entity is setup with the following information and is loaded by two seperate users:

Product name: Dopefish Figurine
Cost:  100
Margin: 10%
Shipping: 5%

Lets say we have a validation rule: Margin + Shipping must be less than or equal to 20% to keep ourselves competitive.

User A changes Margin to 15% - still valid, but only just.
User B changes Shipping to 15% - still valid, but only just.

Both save - everything works out fine because their entities are valid.

Anyone else loads that entity and can no longer save it and it is invalid the moment is loaded as the two values combined are now 30%. This fails as we only tested the values we were updating and not some measure that everything else was still as expect - exactly the purpose of the lock field.

Note: If you absolutely want fine grained control on your update without optimistic concurrency then set an aggregate name on the property. The field will then only be loaded 1. when accessed or 2. when the entity is loaded with the aggregate name. If not loaded then LightSpeed will not include it in the update if there is one required and thus will save you having to update the property that you want to avoid.

Optimistic concurrency: Yes, optimistic concurrency is managed via having the lock field on your database table. You can find more information about this in the help documentation.

I hope that helps and appreciate your feedback on this :-)

John-Daniel Trask

Hi JD, thanks for a descriptive answer.

I understand your point of view, and you have a valid case with dependent columns situation. But as this is a special case, or better said, maybe not applicable all the time, I was thinking you will consider giving an option to your users of going the partial-updating-concurrency-detection-way, if they want to. Similar like you said for partial updates - If I want it despite the heavier resource consumption, I will enable it.

But OK, if it's a must, we will have all tables with row version column. Let's see what you will prepare for us regarding field change tracking and how will it be usable in concurrency resolving (hopefuly we will be able to resolve some concurrencies without buging the operators of our application).