Closed uksus70 closed 7 years ago
Hi, thanks for posting. Could you describe steps to reproduce this issue? Was it reproduced in Parallel or Sequential ExecutionMode of the TableSet?
I don't specify ExecutionMode anywhere. I suppose some default mode is used then.
It would be great if you could be able to write failing test and send a pull request with it.
Current test set for AddOrUpdate
method: https://github.com/dtretyakov/WindowsAzure/blob/master/test/WindowsAzure.Tests/Table/Context/AddOrUpdateEntitiesTests.cs
I've also encountered this issue recently and have found the cause of it. In my call to TableSet.Add(IEnumerable<TEntity> entities)
(or any other batched operation) I'm not interested in the returned entities so I simply call it like so
Table.Add(toAdd);
Unfortunately, because Add
returns an un-executed IEnumerable
and that I'm not evaluating it myself then the underlying execution never actually occurs.
From a client code perspective the solution is to just evaluate the result of the call, e.g.
var results = Table.Add(toAdd).ToArray();
However, I can see many people falling into this trap as you often don't care about getting the entity back after an add. To solve this, the simple fix of evaluating the execution of the batches in TableRequestSequentialExecutor
does the trick
Old
return from batch in batches
from result in _cloudTable.ExecuteBatch(batch)
select _entityConverter.GetEntity((DynamicTableEntity)result.Result);
New
return from batch in batches
from result in _cloudTable.ExecuteBatch(batch).ToArray()
select _entityConverter.GetEntity((DynamicTableEntity)result.Result);
I'll submit a pull request for this fix soon.
If there is an error while adding some record,
AddOrUpdate
method just exists silently without reporting an error. Is it expected behaviour?