We use LLBLGenPro version 2.6, with .Net Framework 3.5 SP1.

We wish to add RemovedEntitiesTracker collections to all collections in a deep graph. We have created a business object API that allows users to fetch the top-level object with either a shallow fetch (just the object), or a full fetch (all PrefetchPaths added).

The issue is this: in order to add the RemovedEntitiesTracker collections, we must reference the mapped entities, which causes the lazy loading logic to kick in during the "shallow fetch" use case. As a result, the benefit of lazy loading is lost, and we end up having tons of queries fire anyhow. Thus, in order to leverage both lazy loading and RemovedEntitiesTracker, we feel that we must do one of the following:

1.) Inject the addition of RemovedEntitiesTracker into the correct place in the template OR 2.) Edit the generated entities to add the RemovedEntitiesTracker when the mapped entity collection is first fetched

Are these the only options?

EDIT: We came up with something: what we did was modify the template for entityInclude, such that it places a User Code Region in the GetMulti() functions in our Entities for their mapped entities. This way, we can add a custom _myEntityCollection.RemovedEntitiesTracker = New MyEntityCollection(), when LLBLGen goes to load the collection for the first time. Thus, we avoid the firing of the load just because we wanted to add like so: MyEntity.MyCollection.RemovedEntitiesTracker = Foo.

Also, this works because the code generator saves our User Code Regions during refreshes.

Is this good/bad/other ?

Thanks

That should work and looks good. Please test it in databinding and other stuff to ensure it works as expected.

daelmo,

Just do update this thread, we abandoned this approach. While we were able to get the templates modified to do a little bit of this, we found that there were too many member variables involved in the state tracking, etc. This was especially true once we walked the generated code and saw all of the myriad ways these items interact with each other.

We did not want to create brittleness, so we had the developer do it himself.

Thanks! cardplayer

Hi Cardplayer -

I have most of this developed already. Just cleaning it up. I have an observer class that maintains & monitors a Root Entity and all it's recursive children for RemovedEntityTrackers. And you can specify a RequirePrefetch flag. So it will not lazy load if you don't want. However, once a collection or entity is lazy-loaded or assigned anywhere in the child tree - the observer automatically jumps in and makes sure the correct RemovedEntityTracker is specified.

Then, each screen has a standard Save routine, which returns a Unit of Work to be saved. These Units of Work allow me to have n-level child screens (each with their own save buttons) or one big save button at the top-level screen with the RootEntity.

All RemovedEntityTrackers (n-levels deep) are automatically added to the Units of Work by the observer class. Thus, when you Save at any level - all Entities that were removed within the tree (from that level on down) are automatically deleted.

Ryan