LLBLGen 3.1.11.415.

I have collections for which I am using a RemovedEntitiesTracker. Sometimes an entity is removed from a collection but subsequently re-added to the collection. In this case I remove the entity from the RemovedEntitiesTracker.

However, I find that when the object graph is serialized, things don't work correctly for entities that have been added to a RemovedEntitiesTracker at some point--the entities relations are not serialized.

The attached project demonstrates this. I have three entities: EntityA, EntityB, and EntityC.

EntityA has a collection of EntityBs and EntityB has a collection of EntityCs.

I fetch an EntityA that has an EntityB that has an EntityC. If I serialize this, everything serializes correctly (EntityA, its EntityB, and its EntityC).

If I remove an EntityB from EntityA's EntityB collection, then add it back, and then serialize EntityA, it works correctly again:

            //Remove the EntityB and then re-add it
            EntityBEntity entityB = entityA.EntityBs[0];
            entityA.EntityBs.RemoveAt(0);
            entityA.EntityBs.Add(entityB);

But if I use a RemovedEntitiesTracker, it breaks:

            //Remove the EntityB and then re-add it, but using a RemovedEntitiesTracker
            entityA.EntityBs.RemovedEntitiesTracker = new EntityCollection();
            entityB = entityA.EntityBs[0];
            entityA.EntityBs.RemoveAt(0);
            entityA.EntityBs.Add(entityB);
            entityA.EntityBs.RemovedEntitiesTracker.Remove(entityB);

In this last case, when I serialize EntityA, it serializes the EntityB, but none of EntityB's relations get serialized.

Is this intentional for some reason?

Reproduced. I'm looking into it.

I think this is what happens:

As removedentitiestracker is a normal entity collection, calling 'Remove(entity)' will do more than just a remove: it will mark the entity to be removed and will tell 'entityc' it's removed.

This will reach entityC but not entityA. The reason for that is that 'RemovedEntitiesTracker doesn't have its containingentity set so it only notifies the entities related to the entity at hand, which are all EntityC's in EntityB's collections.

EntityBs does have its containingentity set (EntityA), so removing entityB from that collection is different.

The code doing all this is very complex, as it's scattered across multiple classes, as it's a chain of calls (using various routes, to avoid infinite loops in the various different scenarios that can occur).

What exactly is the reason an entity can be moved back from removed entities tracker to the real collection?

This came up for me in the user interface that uses these entities (through a facade API layer). In a dialog box where the user is editing EntityA, there is a list box of the EntityBs. As the user adds, removes, and reorders EntityBs from the list, the underlying collection is not immediately updated; this happens only when the user closes the dialog. At this point, rather than synchronizing the collection with the listbox one entity at a time, the code just removes everything from the collection, then adds back the items that are in the listbox.

(I'm swapping in LLBLGen to replace the persistence framework that was used behind the facade previously, and with the old framework this approach worked fine.)

I can change the user interface code to work around this, but I'm worried about external developers who are using the API to interact with the product and who may be using a similar pattern.

ww wrote:

I can change the user interface code to work around this, but I'm worried about external developers who are using the API to interact with the product and who may be using a similar pattern.

If you could workaround this, that would be good. Maybe you can keep track of the indexes to delete at the end of the user interaction. This is specific to SelfServicing paradigm. If you found inconveniences in using this you could consider using [urldescription="Adapter template set"]http://llblgen.com/documentation/3.0/LLBLGen%20Pro%20RTF/hh_goto.htm#Concepts/concepts_templatesets.htm[/url].

I am using Adapter. Sorry I forgot to mention that.

Sorry I made a mistake. This is the same behavior for both Adapter and SelfServicing. The logic comes from the CollectionCore. So again, you will have to take this into account to write a workaround in your code.