Jens Schauder
Jens Schauder
While probably not often used I don't see anything inherently wrong with deleting with an empty criteria. After all we also have `deleteAll` in the `CrudRepository`. And we absolutely have...
I discussed this topic with the team and we decided that we are not going to produce events for deleted aggregates. Therefore we can and should delete them directly without...
No, we still delete related entities, just as with `deleteById` but we don't load the aggregates first. So if we have an aggregate root `A` which has a collection of...
Locking is a good point. Delete by query should behave just as `deleteAllByIds` in this regard.
We don't need the locks for R2DBC, because we don't operate on multiple tables there, so there is no risk of a deadlock, which was the reason for introducing locking...
A PR would be appreciated. But be warned, I don't consider this a good first issue, since the code generation is rather complex. But if you still want to give...
A first PR should fix the bug. If it improves performance that would be great. But correct goes before fast.
Changed this issue to upgrade to 4.2.4 instead of 4.2.3 since the 4.2.3 version did not fix the index out of bounds problem when the allocator property was removed.
I agree that it would be nice to move `AggregateReference` into `relational`. But in order to not confuse people more than necessary, we should properly support it in R2DBC. For...
And we should do it in a backward compatible way. I.e. create a new `AggregateReference`, let the old one extend the new one and deprecate it.