Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> Problem with re-adding item to collection when using RemovedEntitiesTracker
 

Pages: 1
Bugs & Issues
Problem with re-adding item to collection when using RemovedEntitiesTracker
Page:1/1 

  Print all messages in this thread  
Poster Message
ww
User



Location:

Joined on:
01-Oct-2004 22:58:25
Posted:
65 posts
# Posted on: 10-Aug-2011 23:14:41.  
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:

Code:

            //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:
Code:

            //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?
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14484 posts
# Posted on: 11-Aug-2011 10:22:13.  
Reproduced.
I'm looking into it.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37476 posts
# Posted on: 11-Aug-2011 13:06:50.  
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?
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
ww
User



Location:

Joined on:
01-Oct-2004 22:58:25
Posted:
65 posts
# Posted on: 11-Aug-2011 16:58:45.  
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.



  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8071 posts
# Posted on: 11-Aug-2011 20:57:26.  
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].
David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
ww
User



Location:

Joined on:
01-Oct-2004 22:58:25
Posted:
65 posts
# Posted on: 11-Aug-2011 21:01:02.  
I am using Adapter. Sorry I forgot to mention that.

  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8071 posts
# Posted on: 11-Aug-2011 21:07:43.  
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.
David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.