Hi,

I have following problem:

When inserting new entities the order of the insert action is crucial.

Lets assume following:

EntityTable -> AttributeTable EntityTable -> RelationTable -> EntityTable

I.E. each entity has attributes and the entities are related via an relationtable.

In order for my code to work I need first the attributes to be saved and then the relations.

Is such a scenario possible?

Thank you

Christoph

Sure, this is the normal behavior for a recursive save.

Just save the graph recursivley (Doesn't matter which entity or collection to use in the save method), as long as you have passed true for recursive save, the framework will smartly insert entities which need to be inserted first to avoid any referential constraint violation.

Yes I know this already

What I want to know if I can take control over the insert queue after the graph is created and before the graph is persistet.

I just want to take care that before the relations are going to be saved the attributes are already saved. Both tables (Attribute, Relation) are related to the element entity and put into the update queue by calling UnitOfWork.AddForSave( entity, predicate, refetch, recursive ) ( the entity in this case is the element )

Any hints?

As far as I know you can control how the graph is built. LLBLGen framework constructs the graph based on the dependencies. The best I can recommend to you is: if you want A.X be saved before B.Y, then AddForSave B.X, then B.Y then B.

You can't directly control the ordering, it's based on how the graph is constructed. So if you want to have A be saved before B, then B has to depend on A, i.e. B has to have a m:1 or 1:1 relationship with A where B is on the FK side.

Then assign A to B, e.g. assign Customer to Order, on its order.Customer property. This way, the graph is traversed, 'Customer' is seen as an entity on which 'order' depends, and Customer is therefore saved before Order.

This process is done using a topological sort of the graph, which makes sure there are no entities saved after the ones they depend on. I therefore don't see why you would want to disturb this process.

Why do you need the attributes to be saved before the relations ? According to your description, they don't depend on eachother?