We did a trial of 5.5.1 against our unit tests and it worked in most cases. However, some of our unit tests failed when adding both parent and child table rows interleaved. The actual code that failed is rather complex, but the core pattern is AddForSave(ParentRowA) followed by AddForSave(ChildRowsOfParentRowA) and then going back to AddForSave(ParentRowB) and AddForSave(ChildRowsOfParentRowB). In our actual use case, the chain from parent to child is deep and there are a variety of children.

I don't have a minimal reproduction available as returned to 5.4.4 for now, so my question is really if this is an expected change due to the Batch feature that was added (a feature that we are interested in exploiting). Previously the unit of work did the inserts in the order we added them to it, now it seems like it may be grouping them even though we didn't set a batch property on the adapter.

Hi John,

I'm sorry but I don't see the failed behavior in your post. What was the behavior in 5.4.4 and how is now? (i.e: what is the order or inserts/updates before and now). How many entities are you saving per parent?

The difference is that 5.4.4 saves the entities correctly, but in 5.5.1 I get FK errors. I don't have the reproduction as I downgraded to 5.4.4 as soon as the failed tests were discovered.

The real question is if there is expected differences between 5.4.4 and 5.5.1 in the way that a unit of work must be constructed. The method we have been using since LLBLGen 2.X continues to work in 5.4. This latest release is the first time I have seen the order that the items were added to the unit of work for save not being respected.

Inserts are indeed grouped per type, as the batch system requires that, however that's not going to cause FK issues. The thing is that the sorting of the elements groups the elements as well in one go otherwise we have to go over the graph multiple times. The sorting is done in such a way that the dependent is always inserted prior to the depending entity.

We did have a bug in the code however where not all entities were inserted in some cases, i.e. when you had multiple graphs in the unit of work. This bug was fixed on December 28th 2018. If you used a hotfix build of 5.5.1 uploaded prior to that date, you ran into this issue. If you used a build released after that, then it's unrelated to this.

However I suspect the issue you ran into is this issue. There's no way the PK side is inserted after a depending FK side, the graph sorter takes care of that. (Using a topological sort of the graph at hand. This code isn't different from earlier versions)

The grouping code does the following:

// now we have to sort the insert queue based on the sorted types list, so all entities belonging to a given type have to be placed in the slot of the type.
// meaning, if we have as sorted types: Customer, Employee, Order, and as entities in the insert queue: Customer1, Order1, Customer2, Order2, Employee1, Order3,
// the insert queue will become: Customer1, Customer2, Employee1, Order1, Order2, Order3. 
// we can skip this step if there's just 1 type or we're processing updates as we'll leave those alone. 

so it abuses the fact that a PK side can always moved to the a spot earlier in the queue as long as it never ends up after an entity of a type that depends on an entity of the type it is of. So a Customer can't end up being inserted after an Order as the type 'Order' depends on the type 'Customer'.

It was this code which botched multiple graphs in a single unit of work (as in: it removed parts of the queue and therefore not all entities were inserted, leading to FK issues). Looking at your description, it's what you had: multiple parent/child mini graphs which weren't connected.

The RTM release of 5.5.1 is scheduled for today, so we'll proceed with that. If you have the same recurring problem after the RTM release of 5.5.1, please post back in this thread asap so we can fix it for you (pending a repro case of course ) as soon as possible so you can utilize 5.5's new features

v5.5.1 RTM is available now. It contains the fix for the issue I described above and which I expect you ran into as well. Please give it a try and if it doesn't fix your problem, then you ran into a different issue and we have to investigate that further.