Hello,

We're on 5.8.5, and currently trying to structure a fairly complex save operation in our code.

We'd like to use the UnitOfWork object to wrap the operation in an all or none transaction, but it fails in this particular workflow. Best guess is that we're adding entity collections to the UnitOfWork object in the incorrect order compared to their database cardinality, and experiencing FK violations.

I've been through the documentation, and I can see that the UnitOfWork object supports setting an operation order (eg Insert Delete Update), but we're wondering if there's any way to assert an entity order or to identify what type of entity each collection in the UnitOfWork represents so that we can set up some sort of background method to build a new one in the correct order.

Any assistance would be appreciated.

Thanks in advance

1) 'General chat' is a generic forum not for support. I've moved your thread
2) please give some more information about what exactly goes wrong.

Thanks Frans. Sorry, first post.

Unfortunately, that's pretty much the extent of the information that we have. We've created a UnitOfWork object, added entity collections to it over the course of a fairly complex workflow, attempted to commit it and had it fail on FK violations on objects that would be created by the same transaction. It's most likely an issue with us adding them in the wrong order.

If there's no property that we can call on the UnitOfWorkElements to identify the entity type, we'll just work around it, we were just investigating the option of building some code to reconstruct the UnitOfWork in the correct order since it would be handy to use elsewhere.

Thanks for the quick reponse.

The unit of work will process the work in groups, so all inserts, all updates, all deletes and you can define in which order these groups are executed. This means that for some inserts an update has to be performed first and for a certain update an insert has to be performed first (so a catch 22), then it can't be solved. The idea is that for updates to work, it's enough to first have all inserts done, because the inserts will provide the PK values that updates might need (you insert a new row with a PK of 4 and then an update which writes 4 for an FK field pointing to that PK side).

So if you first run all inserts, then all updates, it should be ok, however if you run into FK violations, please check what is happening: enable tracing to see which SQL queries are produced or use the ORM Profiler to see what's going on (free tool that comes with an active subscription).

The only thing I can think of which might go wrong if is you have a unique constraint and you want to place a new value in that UC through either insert or update it goes wrong because the row which already has that value is scheduled for delete after those actions. In that case run the deletes first.

You can specify the ordering in the Unit of work constructor