eTAG in LOCK scenario, is it a must that we should have a field like Timestamp?

[cain_sun]

Hi experts,

In most of the eTAG scenarios,  field like UPDATED_AT is used as the check field. IF-MATCH ill compares whether the value of this field is changed or not to see whether someone else changed this data. But in some cases, there is no such fields in the DB table that can indicates changes happen, does this mean eTAG cannot be used in this case?

[former_member184867 · Accepted solution]

To enable ETAG you need at least one property in the Entity definition,  that will hold the version information of the entity at runtime. For example: you have an entity say PurchaseOrder that has two properties.

PurchaseOrder

|_____  PO_NUMBER

|_____ PO_AMOUNT

Now lets say your current PO looks like :

PO_NUMBER      PO_AMOUNT

===========     ===========

111                      100 

After an update the same PO looks like

PO_NUMBER      PO_AMOUNT

===========     ===========

111                      150

This is perfectly fine, but just looking at the data no one can tell which one is latest. Here you need some kind of version information with the data that tells which version is latest and correct.

Lets introduce a new field called VERSION in Entity PurchaseOrder.

Now lets say your current PO looks like :

PO_NUMBER      PO_AMOUNT       VERSION

===========     ===========       =======

111                      100                        1

After an update the same PO looks like

PO_NUMBER      PO_AMOUNT    VERSION

===========     ===========   ========

111                      150                        2

Here looking at the data you can easily say which version is correct and latest.

Timestamp field acts as an easy mechanism for versioning.

So the bottom line is you need one field for to describe the version of your data. Sometimes timestamp is the easiest choice. If it is not timestamp you need to handle the version with some extra effort.

Hope this clarifies your doubt

Regards

Atanu

[cain_sun · Accepted solution]

hi Astanu,

Thanks for your explanation. Yes I got what you mean. Actually, timestamp field is just a example in my question to represent the VERSION field. And I think this VERSION field should be stored to DB, so that the next update can check it. Can I say eTAG is based on the structure of the entity set? There must be a field which can work like VERSION?

But in some cases, there is no such VERSION field in the DB table(data model) like UPDATE_AT. If I cannot find any field for VERSION management in the enittyset.

Can we have some calculation based on the current data line and got some identify value? Or can we use the whole data line as eTAG field?

[EkanshCapgemini · Accepted solution]

Hi Cain,

If there is no field which can act as a version, you can create HASH of the line/record and use that as Version control field. Once you are reading the record, generate HASH of the record(for example, you can concatenate all the fields in a string and use this method to generate hash value) and pass it back to version field. If there is any modification in that row, the hash value would change.

Regards,

Ekansh

[cain_sun · Accepted solution]

hi Ekansh,

Your answer is exactly what I am looking forward to! Thanks.

[AshwinDutt]

Hello Sun,

Not necessarily it has to be the date.

We can use any other field which can help us to find out if its already modified or not.

Regards,

Ashwin