estoy actualizando un objeto en AzureTableStorage usando la biblioteca StorageClient conActualizar un objeto a Azure Table Storage: ¿hay alguna manera de obtener la nueva marca de tiempo?
context.UpdateObject(obj);
context.SaveChangesWithRetries(obj);
cuando hago esto, ¿hay alguna manera de controlar la nueva marca de tiempo para obj sin hacer otra petición al servidor?
Gracias
Stuart
MSDN page tiene alguna orientación sobre el uso del campo de marca de hora:
Marca de tiempo Propiedad
La propiedad de marca de hora es un valor DateTime que se mantiene en el lado del servidor para registrar el tiempo una entidad era última modificación. El servicio de Tabla usa la propiedad Marca de tiempo internamente en proporciona concurrencia optimista. Usted debe tratar esta propiedad como opaca: No debe leerse ni configurarse en operaciones de inserción o actualización (se ignorará el valor ).
Esto implica que es muy detalles de implementación del almacenamiento de tablas, que no debería depender del campo Marca de tiempo para representar fecha y hora de la última actualización.
Si desea que un campo que está garantizado para representar el tiempo de la última escritura, crear nuevo campo y la puso en cada operatio actualización. Entiendo que esto es más trabajo (y más espacio de almacenamiento) para mantener el campo, pero eso realmente resolvería automáticamente su pregunta: cómo recuperar la marca de tiempo, porque ya lo sabría cuando llame a context.UpdateObject().
Yo no lo creo, por lo que yo sé Timespan y Etag se establecen por sí mismo Azure Storage.
Para complementar Seva Titov's answer: informó el extracto era válida al menos hasta mayo de 2013, pero en noviembre de 2013 se ha cambiado (énfasis añadido):
La propiedad de marca de hora es un valor DateTime que se mantiene en el lado del servidor para registrar la hora en que se modificó por última vez una entidad. El servicio Table usa internamente la propiedad Timestamp para proporcionar concurrencia optimista. El valor de Timestamp es un valor monótonamente creciente, lo que significa que cada vez que se modifica la entidad, el valor de Timestamp aumenta para esa entidad. Esta propiedad no se debe configurar en operaciones de inserción o actualización (el valor se ignorará).
Ahora la propiedad Timestamp ya no es considerado como opaco y está documentado que su valor aumenta después de cada edición - Esto sugiere que podría Timestamp se puede ahora utilizar para realizar un seguimiento de las actualizaciones posteriores (al menos en lo que respecta a la entidad única).
Sin embargo, a partir de noviembre de 2013, todavía es necesaria otra solicitud de almacenamiento de tabla para obtener la nueva marca de tiempo cuando actualice la entidad (consulte la documentación del método Update Entity REST).Solo cuando inserting an entity el servicio REST devuelve la entidad completa con la marca de tiempo (pero no recuerdo si esto está expuesto por la biblioteca de almacenamiento StorageClient/Windows Azure).
Lo es, pero es posible que deba analizar ese valor usted mismo. El código para esto está en github y se puede encontrar aquí, https://github.com/Azure/azure-storage-net/blob/68c3ee55a3a6f62a0159cea58005d3fe027312a8/Lib/WindowsRuntime/Table/Protocol/TableOperationHttpResponseParsers.cs#L754 más específicamente, estas marcas de tiempo son claramente marcas de tiempo de Lamport e incluso si Microsoft le dice que no asume nada sobre ellas, sí aseguran que siempre crezcan en una dirección en cada cambio, sin embargo, es solo pseudo tiempo, no realmente el tiempo, pero lo suficientemente cerca. –
estoy usando Windows Azure Storage 7.0.0
y se puede comprobar el resultado de la operación para obtener los eTag y las propiedades Timespan:
var tableResult = cloudTable.Execute(TableOperation.Replace(entity));
var updatedEntity = tableResult.Result as ITableEntity;
var eTag = updatedEntity.ETag;
var timestamp = updatedEntity.Timestamp;
La propiedad Timestamp es en realidad un Lamport timestamp. Se garantiza que siempre crecerá con el tiempo y, aunque se presenta como un valor DateTime, en realidad no lo es.
En el lado del servidor, es decir, almacenamiento de Windows Azure, para cada cambio hace esto:
nextTimestamp = Math.Max(currentTimestamp + 1, DateTime.UtcNow)
Esto es todo lo que hay que hacer. Y, por supuesto, está garantizado que suceda de forma transaccional. El objetivo de todo esto es proporcionar un reloj lógico (función monotónica) que se pueda utilizar para garantizar que el orden de los eventos suceda en el orden previsto.
Aquí hay un enlace a una versión del actual WAS paper y si bien no contiene ninguna información sobre el esquema de marca de tiempo específicamente tiene suficientes cosas allí que rápidamente se da cuenta de que solo hay una conclusión lógica que puede sacar de esto. Cualquier otra cosa sería estúpido. Además, si tienes alguna experiencia con LevelDB, Cassandra, Memtables y su estilo, verás que el equipo de WAS siguió la misma ruta.
Aunque debo aclarar que, dado que WAS proporciona un modelo de coherencia fuerte, la única manera de mantener la marca de tiempo es hacerlo con candado y llave, por lo que no hay manera de adivinar la próxima marca de tiempo correcta. Debe consultar WAS para obtener la información. No hay forma de evitar eso. Sin embargo, puede mantener un valor anterior y presumir que no cambió. WAS le dirá si lo hizo y luego podrá resolver la condición de carrera de la forma que mejor le parezca.
Gracias Seva - Ya estaba usando un campo adicional, solo buscando ver si había alguna forma de usar el campo autogenerado. – Stuart