Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> Entity is marked as dirty after a property for a referenced entity has been set to the same instance
 

Pages: 1
Bugs & Issues
Entity is marked as dirty after a property for a referenced entity has been set to the same instance
Page:1/1 

  Print all messages in this thread  
Poster Message
Kazak1
User



Location:

Joined on:
30-May-2006 18:59:16
Posted:
39 posts
# Posted on: 04-Jan-2008 20:30:33.  
VS2005
Adapter
2.0.0.0 Final (July 6th, 2007)
Oracle 10g

Say, I have two entities ParentEntity, ChildEntity with an optional PK-FK relationship. Hence ChildEntity.ParentId is nullable in the database and generated as a Nullable<int>.

Now, let's fetch a ChildEntity with a prefetch path to bring ParentEntity as well. If after that I set the ChildEntity.Parent property to another (or the same) fetched instance of ParentEntity with the same ParentId, the ChildEntity gets marked as dirty.

Code:
...
IPrefetchPath2 prefetchPath = new PrefetchPath2((int)EntityType.ChildEntity);
prefetchPath.Add(ChildEntity.PrefetchPathParent);

ChildEntity child = new ChildEntity(100);
adapter.FetchEntity(child, prefetchPath);

child.Parent = child.Parent;
...


This does not happen when the relationship is mandatory.

Please advise

  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37812 posts
# Posted on: 05-Jan-2008 11:32:10.  
It first desyncs the Parent from the child, then re-syncs the PK of parent with the FK in child, hence the dirty flag set.

What I find a bit odd is the fact that you say it won't happen when the relation is mandatory (i.e. the FK field is a normal value type, not a nullable type). is that only with value types or with string FK fields as well?

I'll see if I can reproduce it with the v2.0 build and also with the v2.5 build to see if the behavior is indeed solved there. We did make some changes in v2.5 in this area.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37812 posts
# Posted on: 07-Jan-2008 10:24:17.  
I could reproduce the behavior on v2.0. Very strange. Looking into it.

(edit) also present in v2.5

(edit). The reason is this:
- when assigning an entity to the property mapped onto the relation (in this case assigning an entity to child.Parent), the original one is desynced first.
- when desyncing has to be done, there's no check if the the new entity is the same as the current entity.
- when desyncing, it will reset the FK fields to null. The optional FK fields are nullable, and therefore this will succeed, making them dirty. The not optional ones aren't nullable, and aren't set to null, leaving them untouched.
- after desync took place, the new entity is synced. this will force the FK fields to be set again. This means that the optional FK fields get a value again, and the not optional fields won't be changed as they have the same value.

Normally, this isn't an issue, as you set the 'parent' to a different entity, I mean: why setting it to the same entity? However in the case where you do this, it is indeed leading to unexpected behavior.

This can't be 'changed' without breaking changes as it is a change in behavior. I'll file a change request for v2.6 where this mechanism is re-examined and if possible a check will be introduced which cuts off the whole assignment pipeline if the same entity is assigned to the property.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
TomV
User



Location:
Belgium
Joined on:
31-Jan-2008 14:22:10
Posted:
76 posts
# Posted on: 02-Jun-2009 09:33:20.  
Hi Otis,

We have this same strange behavior and using version 2.6 Final (August 18th, 2008 ).
Any idea when this will be solved?

Kind regards,
TomV


Life goes fast, it must be riding a Ducati!  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37812 posts
# Posted on: 02-Jun-2009 10:36:58.  
TomV wrote:
Hi Otis,

We have this same strange behavior and using version 2.6 Final (August 18th, 2008 ).
Any idea when this will be solved?

Kind regards,
TomV

What's the runtime library build nr you're using? We did have 2 bugfixes in the runtime lib regarding dirty flagging in v2.6, so it might be you're using an out-dated runtime lib. Please download the latest build and see if that indeed fixes your problem.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
TomV
User



Location:
Belgium
Joined on:
31-Jan-2008 14:22:10
Posted:
76 posts
# Posted on: 02-Jun-2009 12:16:42.  
Hi Otis,

I used the runtime libraries of 28th of october and now switched to the runtime of 12th of may. It's still a problem.

While searching a solution for my problem/bug I came out on this thread. After more in depth studying I see that our problem is a little different than the one originally stated.

So this probably is somewhat hijacking this thread, so I probably need to create a new thread for this any way.

But for now we have a workaround as we changed
DeviceEntity.DeviceParentId = newValue into DeviceEntity.DeviceParent = parentObject.

For us things are working now...


Kind regards,
TomV


Life goes fast, it must be riding a Ducati!  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37812 posts
# Posted on: 02-Jun-2009 12:20:18.  
If it's a bug, I still would like to have more info so we can fix it. Regular Smiley So if it's not too much trouble, please open a new thread and explain the problem.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


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

Version: 2.1.12172008 Final.