First, thank you for your time, effort, and contribution to the community.
Second, I'm having some issue(s) with the Change Tracking / Updating. My commentary assumes I'm following the code 100%. (I've also hacked together Session/Tracking support so I'm not sure if what I'm experiencing is an artifact of that).
a) The EntityCollection update logic doesn't make 100% sense to me.
b) Assuming some of the above holds true entry.Refresh(entity) and my understanding of the Refresh method is to compare the "original state" to the new/proposed change/update. Then I think the OriginalValues and CurrentValues is reversed and EntityEntry should really look like:
Should be like:
Actually, I think I'm better understanding how EntityEntry works...... And issues I'm facing could very well be due to my hacked implementation of sessions....(More digging required)
EntityEntry is holding a reference to the current object and when that is being changed, that is how it's getting tracked. (Which makes sense why CurrentValues = Entity.ToBsonDocument()).
I think somewhere along the line I'm getting a new object of the same entity. So, when I'm making changes to this entity, it's not reflecting in EntityEntry.
Flipping things around resolved the issue, but isn't "in the spirit" of the originally intended code...
Ok..... I may have found the actual issue (and helped answer my questions around EntityCollection and the comparison).
should be changed to:
The original intent of code was to check the object references with the default behavior of .Equals. The problem is: If the entities being tracked have an overridden Equals (which isn't uncommon and actually recommended in Domain Driven Design), then you aren't actually comparing the object references.
I believe the right fix (to stay inline with existing spirit of code) is to do an explicit Object.ReferenceEquals.
Your assumption is right - the
The "else" branch in that code block is for the ID check. If two entities match via ID but are different via entity reference, we want to remove the old entry and add the new entry.
Feel free to share your implementation of sessions here if you want any pointers - I know my internal API is a little unstable between releases. I've been toying with the idea to implement sessions/transaction support (see #34) though there have been a few roadblocks to implementing something like it natively in the library. There are also a few other things I'd like to land before supporting sessions too (#112 and #110) which will delay me implementing it even further.
The fix for using