Update not triggered, and GetMemberEntityCollections not called

Posts   
 
    
Posts: 3
Joined: 09-Dec-2015
# Posted on: 29-Dec-2015 21:07:09   

We are having a problem with updated value not actually updating/inserting, after upgrading from LLBLGen 3.1 to 4.2 recently. We're using the preset for the Two Classes Deprecated adapter.

In the MyAccountEntity class that's generated, we have an override of GetMemberEntityCollections. This is called from external code, after we call SaveEntity on the DataAdapter. Or, it was in 3.1. However, in 4.2, the GetMemberEntityCollections method isn't being hit, nor is the one in the AccountEntity class. Since we're not calling it explicitly, and it's happening somewhere inside of the SaveEntity call, we need to know what might have changed with that call.

Also, in many places, the code we've generated from the Deprecated templates is now using IEntityCore, instead of IEntity2. That's not the case everywhere. Could that be part of this problem?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 30-Dec-2015 20:58:09   

Is this the same as this thread: http://www.llblgen.com/tinyforum/GotoMessage.aspx?ThreadID=23555&MessageID=134029

As it looks like you have a lot of custom code added by a 3rd party doing things on its own so we have no control over whether that's either bug free code or not.

Frans Bouma | Lead developer LLBLGen Pro
daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 30-Dec-2015 21:12:00   

Please show us your relevant code to understand what are you actually doing.

BTW, it's recommended to leave TwoClasses preset and migrate to partial classes.

David Elizondo | LLBLGen Support Team
Posts: 3
Joined: 09-Dec-2015
# Posted on: 30-Dec-2015 21:14:53   

So, that is a thread from a coworker who has been working with LLBLGen for longer than I have, I didn't know he'd posted, though. But, yeah - this is related, though the upgrade to 4.2 has caused more problems than I'm describing here.

I've found a little more info, now. In the SD.LLBLGen.Pro.ORMSupportClasses.ObjectGraphUtils.ProduceAdjacencyLists method, it used to call the GetMemberEntityCollections method on the IEntity2 that was passed in. Now, it looks like that entity is a TEntity, and so GetMemberEntityCollections isn't called.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 30-Dec-2015 21:40:04   

The thing is simple: whatever relationships there are in the model, if you add entities to collections in an entity, they will be discovered by the framework during save. So the entities you're trying to save as well are not entities which are related to the core entities your saving, in the model: the relationships are added in code somewhere and your code tries to make sure they're included in the queue when that queue is created (by the depth-first-search over the graph in objectgraphutils).

So if your entities are added to collections which are in the model, they're saved without any effort. If that's not the case, because the relationships don't actually exist, you have to make sure the entities are saved when the graph is saved, e.g. through a unit of work.

If the particular method isn't called anymore, that can be the case: we did make a change to the algorithm slightly as there was a complex edge case situation where traversal could skip graph sections. I'm not sure how to help you, as the framework works as expected. We'll continue in the other thread as it's about the same issue.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 30-Dec-2015 22:14:41   

I'd like to continue a bit here, as it is indeed slightly different, but still related to the other thread.

The code is here: http://referencesource42.llblgen.com/#SD.LLBLGen.Pro.ORMSupportClasses/Miscellaneous/ObjectGraphUtils.cs,172

it has indeed changed as you can see: the data you want to persist has to be returned by one of the 3 methods called (see line above). Depending and Dependent are different in that they're used differently: depending are persisted after and dependent are persisted before the entity in question. The member collections are always 1:n and thus persisted after. So the easiest would be to append your entities to the resultset returned by GetDependingRelatedEntities()

This can't be done in the codebase, other than using the deprecated templates and override GetRelatedData() instead of GetMemberEntityRelations().

If you want to get rid of the deprecated templates, you have to make a small adjustment to the shipped normal templates where you change the generated method by appending a partial method call to it. After that you can then add the extra code to the partial method in a partial class.

Frans Bouma | Lead developer LLBLGen Pro
jg
User
Posts: 25
Joined: 29-Dec-2011
# Posted on: 30-Dec-2015 22:23:14   

Thank you! I will pursue this, now. It sounds like something we can get implemented rather quickly. I really, really appreciate this response!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 31-Dec-2015 10:27:08   

I'll close this thread now, and will continue in the other thread simple_smile

Frans Bouma | Lead developer LLBLGen Pro