Re: Problem with saving entities that have one-to-one (1:1) relationships

I have a table structure that looks like this:

Order contains 1..n OrderComponent. OrderComponent has a 1:1 relationship with OrderComponentDetail.

When calling DeepSave, or just trying to call DataRepository.OrderComponentProvider.Save, I get an error that looks like this:

Item has already been added. Key in dictionary: 'Vge.Cavalier.Entities.OrderComponentDetail'. 

What appears to be happening is that when the AcceptChanges method is called on the OrderComponent, it tries to make a copy of all the objects inside itself, including the OrderComponentDetail. When the OrderComponentDetail in turn tries to copy all of the stuff internal to it, one of the things it tries to copy is the pointer back to the OrderComponent. This results in the error I mentioned above. If the exception didn't get thrown, I think there would be infinite recursion.

bslatner,

 Could the problem you describe be related to the one mentioned here http://community.codesmithtools.com/forums/p/5668/24286.aspx

Yes, it certainly looks similar to that problem. I'm not sure what to do about it, though. Do you think I should apply the patch in that thread?

Hello,

I would apply that patch in that thread. If it doesn't work, you can always revert back and let us know, so we can further assist you.

Thanks

-Blake

Actually, I'm pretty sure the patch in the other thread doesn't apply here.

There've been many revisions to EntityProviderBaseCore.cst since the patch was created. Some of them seem to be directed at fixing the problem the patch was meant to correct in the first place.

After further investigation, my problem doesn't even seem to have to do with the deepHandles dictionary in EntityProviderBaseCore.cst, but rather with the "existingCopies" dictionary passed to each entity's Copy method.

I experience the exact same issue when using DeepLoad. When I try to DeepLoad one of my entities -- depending on how the child data is structured -- I get the same error message.

The problem with DeepLoad (mostly) goes away if I turn off the useEntityTracking attribute in my web.config. If I turn off useEntityTracking, the exception no longer gets thrown,

    a) It doesn't actually load all the child entities. For example, one entity has a collection of children (call this Collection A), each of which has its own collection of children (call these Collection B). Some collection B get loaded, some don't. There's no particular pattern to it.

    b) if you turn off use entityTracking, the code does some really insane stuff. For example, if I have entity A which owns a B which in turn owns a collection of C, the code to DeepLoad C will call DataRepository.BProvider.GetXxx for EVERY SINGLE C. Extremely inefficient!

So, all that said, I'm still having a problem. I'm able to work around it, for now, by manually doing all the work I was hoping DeepSave and DeepLoad would do.

I think this, again, boils down to netTiers really not understanding 1:1 relationships very well. I don't know enough about the guts of it, as yet, to know where to look for a solution.

Okay, I have created a small, repeatable test case.

Download here: http://www.slatner.com/quick/NetTiersDeepTest.zip

This demonstrates the problem using DeepLoad. Same thing happens with DeepSave.

I could describe the problem in words, but looking at this picture is easiest:

The problem arises when the DeepLoad (or DeepSave) call goes to load the stuff in GroupingInComponentItem. It sees that GroupingInComponentItem owns a TList<ThingComponentDetailLineItem> and tries to populate that. That's where everything goes kablooey.

 Hello,

We have added this to our to-do list. You can check the status of this here

Thanks

-Blake

Thanks very much Blake.

As a temporary (possible) solution...is there any way to tell netTiers NOT to try to express a FK relationship in code? i.e., if I have A with a FK relationship to B, can I use the mapping file (or similar) to simply tell it to ignore that relationship?

No, unfortunately I don't believe there is.  What we had to do in our DB is remove a FK to one of our tables when we had issues like this.  We hated doing it, but we weren't going to lose much sleep over it.  We created an index on that column in the other table so we would still be able to retrieve by that column.

I think your problem is in the fact you have a circular reference?  I haven't spent much time studying your diagram or your code to see what happens.  Just a guess from reading some of your posts.  This is something that will hopefully be on the road map for nettiers.  I would like for it to know when there is a circular reference, and not generate that link that makes it recursive in code. 

Anyway, maybe my suggestion above will help, or it might make you think we were crazy as well lol.

jeff