Updating an object to Azure Table Storage - is there any way to get the new Timestamp?

I'm updating an object in AzureTableStorage using the StorageClient library with

    context.UpdateObject(obj);
    context.SaveChangesWithRetries(obj);

when I do this, is there any way to get hold of the new timestamp for obj开发者_Go百科 without making another request to the server?

Thanks

Stuart

To supplement Seva Titov's answer: the excerpt reported was valid at least until May 2013, but as of November 2013 it has changed (emphasis added):

The Timestamp property is a DateTime value that is maintained on the server side to record the time an entity was last modified. The Table service uses the Timestamp property internally to provide optimistic concurrency. The value of Timestamp is a monotonically increasing value, meaning that each time the entity is modified, the value of Timestamp increases for that entity. This property should not be set on insert or update operations (the value will be ignored).

Now the Timestamp property is no longer regarded as opaque and it is documented that its value increases after each edit -- this suggests that could Timestamp could be now used to track subsequent updates (at least with regard to the single entity).

Nevertheless, as of November 2013 it is still needed another request to Table Storage to obtain the new timestamp when you update the entity (see the documentation of Update Entity REST method). Only when inserting an entity the REST service returns the entire entity with the timestamp (but I don't remember if this is exposed by the StorageClient/Windows Azure storage library).

MSDN page has some guidance on the usage of Timestamp field:

Timestamp Property

The Timestamp property is a DateTime value that is maintained on the server side to record the time an entity was last modified. The Table service uses the Timestamp property internally to provide optimistic concurrency. You should treat this property as opaque: It should not be read, nor set on insert or update operations (the value will be ignored).

This implies that it is really implementation details of the table storage, you should not rely the Timestamp field to represent timestamp of last update.

If you want a field which is guaranteed to represent time of last write, create new field and set it on every update operatio. I understand this is more work (and more storage space) to maintain the field, but that would actually automatically resolves your question -- how to get the timestamp back, because you would already know it when calling context.UpdateObject().

The Timestamp property is actually a Lamport timestamp. It is guaranteed to always grow over time and while it is presented as a DateTime value it's really not.

On the server side, that is, Windows Azure Storage, for each change does this:

nextTimestamp = Math.Max(currentTimestamp + 1, DateTime.UtcNow)

This is all there is to it. And it's of course guaranteed to happen in a transactional manner. The point of all this is to provide a logical clock (monotonic function) that can be used to ensure that the order of events happen in the intended order.

Here's a link to a version of the actual WAS paper and while it doesn't contain any information on the timestamp scheme specifically it has enough stuff there that you quickly realize that there's only one logical conclusion you can draw from this. Anything else would be stupid. Also, if you have any experience with LevelDB, Cassandra, Memtables and it's ilk, you'll see that the WAS team went the same route.

Though I should add to clarify, since WAS provides a strong consistency model, the only way to maintain the timestamp is to do it under lock and key, so there's no way you can guess the correct next timestamp. You have to query WAS for the information. There's no way around that. You can however hold on to an old value and presume that it didn't change. WAS will tell you if it did and then you can resolve the race condition any way you see fit.

I am using Windows Azure Storage 7.0.0

And you can check the result of the operation to get the eTag and the Timespan properties :

var tableResult = cloudTable.Execute(TableOperation.Replace(entity));
var updatedEntity = tableResult.Result as ITableEntity;

var eTag = updatedEntity.ETag;
var timestamp = updatedEntity.Timestamp;

I don't think so, as far as I know Timespan and Etag are set by Azure Storage itself.