Imagine you have a parent and child entity. Load a parent instance. Create new child instance and link it to parent instance through child's property. Create another child instance and link it to parent. Add first child instance to UnitOfWork2 and serialize UoW. The question: What will contain (and try to save when Commit) UoW?

Load a parent instance. Create new child instance and link it to parent instance through child's property. Create another child instance and link it to parent.

May I conclude that this is a 1:m relation, i.e. one parent can have many children. And therefore when you link a child to a parent, you actually add it to the children Collection property of the Parent, right?

So if you pick a child (any entity in a graph), and you set the recurse boolean parameter to true when using UoW.AddForSave() then the entire graph should be added to the UoW, and hence serialized.

Walaa wrote:

May I conclude that this is a 1:m relation, i.e. one parent can have many children. And therefore when you link a child to a parent, you actually add it to the children Collection property of the Parent, right?

Right.

Walaa wrote:

So if you pick a child (any entity in a graph), and you set the recurse boolean parameter to true when using UoW.AddForSave() then the entire graph should be added to the UoW, and hence serialized.

Indeed and this is a big problem sometimes. First because it is not obvious. Second because you can't easily remove the "deleted new entity". The only way to avoid saving of a ghost is to remove it from every parent (direct or indirect) entity in the graph. Which might be very very difficult, depending on the graph. If you take a look at Dataset - this process is straightforward: you remove the row (and child rows are removed as well) and you are certain that the row won't be saved.

Perhaps a new property on entity base is required: IsRemoved or something. That'd mean that UoW should ignore ignore the particular entity and its children. Or perhaps an enhancement to the Uow?

Second because you can't easily remove the "deleted new entity".

Would a Context be helpful here? As there would be one instance of each entity (including new ones), so removing an entity should be reflected everywhere.

Walaa wrote:

Second because you can't easily remove the "deleted new entity".

Would a Context be helpful here? As there would be one instance of each entity (including new ones), so removing an entity should be reflected everywhere.

Are you saying that if I'd use a context in my example (add each entity to the context when they are created) and if I'd just removed the "ghost" entity from the context then UoW wouldn't include it in save operation?

mihies wrote:

Imagine you have a parent and child entity. Load a parent instance. Create new child instance and link it to parent instance through child's property. Create another child instance and link it to parent. Add first child instance to UnitOfWork2 and serialize UoW. The question: What will contain (and try to save when Commit) UoW?

Depends if you've specified to recursively save the entity you added. You can specify not to recursively save the graph.

When you set OptimizedSerialization to true, the UoW will first calculate the save queues and then serialize the entities in the save queue. A known issue currently is that in your situation parent and the other child will still be serialized as they're in the graph reachable from the child to save.

When saving, the entity which is added for save (but not recurse) is then saved. When you used the overloads to add an entity without specifying the recurse flag, the save is recursive, and parent and the other child will be saved as well.

Walaa wrote:

Second because you can't easily remove the "deleted new entity".

Would a Context be helpful here? As there would be one instance of each entity (including new ones), so removing an entity should be reflected everywhere.

Imagine your child is a huge one - it has a lot of children on its own. Does removing the context from the master removes it from its children as well (i.e. recursive delete)? Does UoW ignore related entities when they don't have (the same) context?

mihies wrote:

Walaa wrote:

Second because you can't easily remove the "deleted new entity".

Would a Context be helpful here? As there would be one instance of each entity (including new ones), so removing an entity should be reflected everywhere.

Imagine your child is a huge one - it has a lot of children on its own. Does removing the context from the master removes it from its children as well (i.e. recursive delete)?

no, additions are recursive, removes aren't.

Does UoW ignore related entities when they don't have (the same) context?

No, the entity graph is what the UoW looks at (or better: the persistence engine)