Page 1 of 1

Unnecessary Timestamp Update on Non-changed Entities

Posted: Wed 25 May 2011 17:13
by Oktane
Hi we are seeing an issue when using Optimistic Concurreny with EF / Devart Oracle Connect.

Our DB structure is this

ContractVersion Table (Master Table)
- Counterparty Table (related to ContractVersion)
- Delivery Table (related to ContractVersion)

Which Translates into the following DTO's (we are using POCO STE's)
ContractVersion containing
- List of 1..N Counterparties
- List of 1..N Deliveries

All 3 tables have a timestamp column. The Timestamp for each is updated with a trigger on the Oracle DB. We currently have (and I have checked the xml in the .edml/.edmx) the Timestamp columns set to StoreGeneratedPattern=Computed and the ConcurrencyMode=Fixed.

When we change all the entities Or the parent Entity (ie the ContractVersion), the Optimistic Concurrency works perfectly. However we have a specific case that we cannot figure out.

If we make a change to the Delivery Entity or the Counterparty Entity, the resulting Update commands for these tables are generated correctly. However, in addition we also have an additional Update of the ContractVersion table, that updates nothing but the Timestamp column (See below for the query picked up via EF Profiler). We have validated that the ContractVersion Entity has no changes (ie its not in a modified/changed state), so are confused as to why this update is being called.

Anybody got any ideas?

The additional command, which is called before the actual changes are executed is as follows -
DECLARE
updatedRowid ROWID;
BEGIN
UPDATE
CONTRACT_VERSION
SET TIMESTAMP = TIMESTAMP

WHERE CONTRACT_VERSION_ID = 20 /* @p0 */ AND
TIMESTAMP = '25/05/2011 17:33:21 +01:00' /* @p1 */
RETURNING ROWID INTO updatedRowid;
OPEN '' /* @outParameter */ FOR SELECT
TIMESTAMP
FROM CONTRACT_VERSION
WHERE ROWID = updatedRowid;
END;

Posted: Tue 31 May 2011 08:27
by Shalex
Sorry for the delay.

Entity Framework engine makes EF-provider (dotConnect for Oracle in this case) generate UPDATE commands for all ancestors of modified entity. If entities-ancestors were not changed, UPDATE (empty) should be created any way. So this behaviour is as designed by Microsoft, and our provider implements this logic.

As we consider on our own and basing on feedbacks from other users, such behaviour is acceptable if the table, the base class of hierarchy is mapped to, has UPDATE-trigger which makes additional actions before/after any update in hierarchy.

It is possible to implement an optional behaviour in one of the next releases of dotConnect for Oracle when empty updates will not be sent to database. Please add this suggestion to our EF UserVoice: http://devart.uservoice.com/forums/1051 ... rk-support.