How to get Upsert to work with SaveChangeOptions.Batch?

Question

For some reason, I can't figure this one out (or it doesn't seem to work right...

But: how do I get the new Upsert to work with Batch updates?  Yes, I'm using the same partition key for the batch and v1.6 of Azure SDK with .NET API's.

Can anyone provide the proper Save command for the context if this is supported?

Thank you!

---

Auto-scaling & monitoring service for Windows Azure applications at http://www.paraleap.com

Answer 1

Hi,

  >> how do I get the new Upsert to work with Batch updates?

I would like to know whether you are using local storage or cloud storage. Currently upsert works in cloud storage, moreover please make sure to set x-ms-version header to 20011-08-18. You can refer to http://blogs.msdn.com/b/windowsazurestorage/archive/2011/09/15/windows-azure-tables-introducing-upsert-and-query-projection.aspx for a non-batch sample. But it will also work for batch scenarios by writing:
 
websiteServiceContext.SaveChanges(SaveChangesOptions.ReplaceOnUpdate | SaveChangesOptions.Batch);

 

Best Regards,

Ming Xu.

---

Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 2

That's what I thought, but here is the error I'm getting (no, I'm not testing against Dev storage):

 

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
  <code>ConditionNotMet</code>
  <message xml:lang="en-US">42:The condition specified using HTTP conditional header(s) is not met.
RequestId:957b7555-b8c4-4411-bb02-0892327c0456
Time:2012-01-15T17:23:50.2751272Z</message>
</error>

And here  is the code that I have for context constructor:

        public MetricsContext(string baseAddress, StorageCredentials credentials)
            : base(baseAddress, credentials)
        {
			this.ResolveType = ResolveEntityType;
            this.RetryPolicy = RetryPolicies.Retry(3, TimeSpan.FromMilliseconds(500));
			this.IgnoreMissingProperties = true;
			this.SaveChangesDefaultOptions = SaveChangesOptions.ReplaceOnUpdate;
			this.IgnoreResourceNotFoundException = true;
            this.SendingRequest += (_, e) => e.RequestHeaders["x-ms-version"] = "2011-08-18";
        }

 

During population of a context, certain entities are added with "context.AddObject()" function, others are with context.AttachTo() with etag of "*" and marked as dirty via context.UpdateObject().  Any instances of entities should qualify for Upsert.  I'm saving less than 100 entities at a time. 

Here is the saving code:

 

                context.SaveChangesWithRetries(SaveChangesOptions.Batch | SaveChangesOptions.ReplaceOnUpdate);

 

Thank you for your help!

 

---

Auto-scaling & monitoring service for Windows Azure applications at http://www.paraleap.com

Answer 3

The Windows Azure Storage Team post announcing Upsert indicates that you use a null ETag (not *) to indicate you want to use upsert. Note that you no longer need to specify ResolveType - that bug has been fixed

Answer 4

The Windows Azure Storage Team post announcing Upsert indicates that you use a null ETag (not *) to indicate you want to use upsert. Note that you no longer need to specify ResolveType - that bug has been fixed

Thank you Neil! Trying out 'null' right now. Can you elaborate on the ResolveType bug being fixed? I didn't realize there was a bug, but that I simply needed to let storage client know what type of an object that I was retrieveing from the table so that it doesnt waste cpu cycles by doing it itself?

---

Auto-scaling & monitoring service for Windows Azure applications at http://www.paraleap.com

Answer 5

Hmm, providing null for ETag returns this error during save:

The condition specified using HTTP conditional header(s) is not met

---

Auto-scaling & monitoring service for Windows Azure applications at http://www.paraleap.com

Answer 6

Looks like the problem was SaveChangesWithRetries. Once, I converted to SaveChanges, errors went away. It seems that Upsert functionality is not supported with Retry logic?

---

Auto-scaling & monitoring service for Windows Azure applications at http://www.paraleap.com

Answer 7

Igor-

The ResolveType issue is documented in the performance post at the top of this forum (item 3):

-- When you execute a query using ADO .Net data services, there are two important names – the name of the CLR class for the entity, and the name of the table in Windows Azure Table. We have noticed that when these names are different, there is a fixed overhead of approximately 8-15ms for deserializing each entity received in a query.

This was described as a bug, which the other post I linked to earlier indicated had been fixed.

Answer 8

Is there any timeline estimate on support for the two new upsert modes in local storage?

Answer 9

Ming,

Is it still necessary to provide both options (VB.NET guy here):

Data.Services.Client.

SaveChangesOptions.ReplaceOnUpdate OrData.Services.Client.SaveChangesOptions.Batch

or can we just do:

Data.Services.Client.SaveChangesOptions.Batch

I did a test with only the "Batch" option specified, and it seemed to work for both updates and inserts in my batch-upsert code.