When doing a DeleteWhere<T> and then a Store(T[]) in the same session (maybe you want to remove something prior to inserting something else in the same transaction and can't just replace by id as they might be random), the Delete command is executed last in the first batch of commands.
I've tracked it down to https://github.com/JasperFx/marten/blob/master/src/Marten/Services/UnitOfWork.cs#L191 where the "operations" (in this case the delete where) is added after the insert commands and hence executed last in that batch. Moving it before the inserts only works unless you have 500 or more commands, in that case it runs first in the second batch, possibly removing everything matching from the first batch.
If we just move the "operations" first the following happens: Say you do a DeleteWhere<T> and then inserts 510 new entities that also might match the delete criteria:
theSession.DeleteWhere<User>(x => x.LastName == "batch-id");
theSession.Store(batch.ToArray()); //510 new entities where LastName might match delete criteria
theSession.SaveChanges();
the following batches of commands would be executed:
Batch1:
11 INSERTS
Batch2:
1 DELETE
499 INSERTS
The first 11 inserted rows will be deleted if they match the delete criteria even though we specified the DeleteWhere before storing new entities.
So the commands aren't always executed in the order they're specified in code.
Not sure it's recommended doing it this way and I can get around it by specifying more properties in the delete criteria, but this might trip someone else up as well.
As for a solution, I don't know of anything given right of the bat as just moving the operations around might cause other things to act strange. Possibly we have to be sure we keep track of the order someone issues a command...
Will look into this more after the weekend if needed.
When doing a
DeleteWhere<T>and then aStore(T[])in the same session (maybe you want to remove something prior to inserting something else in the same transaction and can't just replace by id as they might be random), the Delete command is executed last in the first batch of commands.I've tracked it down to https://github.com/JasperFx/marten/blob/master/src/Marten/Services/UnitOfWork.cs#L191 where the "operations" (in this case the delete where) is added after the insert commands and hence executed last in that batch. Moving it before the inserts only works unless you have 500 or more commands, in that case it runs first in the second batch, possibly removing everything matching from the first batch.
If we just move the "operations" first the following happens: Say you do a
DeleteWhere<T>and then inserts 510 new entities that also might match the delete criteria:the following batches of commands would be executed:
The first 11 inserted rows will be deleted if they match the delete criteria even though we specified the DeleteWhere before storing new entities.
So the commands aren't always executed in the order they're specified in code.
Not sure it's recommended doing it this way and I can get around it by specifying more properties in the delete criteria, but this might trip someone else up as well.
As for a solution, I don't know of anything given right of the bat as just moving the operations around might cause other things to act strange. Possibly we have to be sure we keep track of the order someone issues a command...
Will look into this more after the weekend if needed.