Column concurrency / optimized update

In this previous thread almost one year ago it was mentioned you do not support updating only changed columns, but you may add it later.

What is the status regarding this? Is it even considered seriously?

From our point of view, this kind of feature also enables "column concurrency" check - concurrency detection only for columns which values have been changed.
In SQL terms looking for this kind of updates:
update tableex
set column3 = @newValue3, column5 = @newValue5
where id = @valueId
and column3 = @oldValue3 and column5 =@oldValue5

I know this feature is connected with entity change tracking, which I believe you (still) don't support. So the same question is with this, is it even considered in near future?

Regarding entity change tracking, I know you care about speed. Maybe this kind of feature can be switched of easily by config. parameter. Change tracking would also enable implementing audit feature easily. Also it would mean more compatibility with Entity Framework's way of thinking (just considering a benefit of getting a developer with EF experience more quickly up-to-speed with Lightspeed).

I know we can try to get some of this features implemented "manually" ourselves. Make change tracking; on row concurrency detection compare old, new, changed-in-meantime values etc. It would help to have some more documentation and code examples in this direction, i.e. suggestions for change tracking, handling OptimisticConcurrencyException (I couldn't really find anything regarding this in Lightspeed documentation or forums).

Hi Mark,

Incidentally I started doing some development on partial updates today (a second attempt at coming up with an elegant way of integrating this capability) so it's certainly planned for it. Ideally it will ship with LightSpeed 3.0.

Entity tracking is not supported publically but we are looking at altering this also in LightSpeed 3.0. We obviously have to track everything internally however we have often elected to not expose absolutely everything as it makes the product more difficult to start using and can overwhelm users. This is a prime reason many customers have chosen LightSpeed over, say, NHibernate. Having said that - it's a balancing act, we don't want to stand in the way of power users - we like people pushing the limits!

Entity change tracking is 100% tied to the partial updates capability. Would you see a need to actually see entity level change tracking publically or would it just be enough to see that your updates were now more efficient? Auditing is something that we are also looking at as a standalone feature but I could see how just exposing a set of changed properties etc would aid in folks developing their own capability.

We are also looking at beefing up the optimistic concurrency documentation and capabilities - specifically instructing what has changed, providing the ability to "refresh" entities from the database, providing original property values and other ideas are all on the table for LightSpeed 3.0.

I really appreciate you taking the time to post your thoughts on this as it does mean we'll be adding additional priority to these features.

John-Daniel Trask

Hi JD,

Thanks for a quick reply. I really like your attitude towards customers (besides liking your product too :)

I think it would be nice to have change tracking exposed, which is the base feature for other features mentioned. Like you said it, it would really aid to develop other capabilities dependend on it, like auditing (until you support it yourself) or something else which your users think-off.
If someone doesn't like it or need it, just switch it off by a parameter.

This "column concurrency" (not sure what is the "official" name out there) instead of row-version optimistic concurrency is something we have possibilities of, as customers could update some description or name, while a standalone server process updates some other data columns triggered by a communication with other systems. Or possibly customers changing different columns for same row at the same time. For us, getting no concurrency exception happening in this situations is a plus to system responsiveness.