Why is Breeze resetting OriginalValues hash map when detaching an entity?

Question

I am using the Sandboxed EntityManager and Partial Entity patterns in my project. In the Sandboxed EntityManager, I have a full entity with changes (Modified) that I would like to apply to my master EntityManager. The approach I am taking is as follows:

1. Detach the "Unmodified" Partial entity that I wish to update from my master EntityManager.
2. Detach the "Modified" Full sandboxed entity from my Sandboxed EntityManager.
3. Attach the detached sandbox entity to my master EntityManager.

The issue I'm experiencing is that the detachEntity() call resets the originalValues hash map on my sandboxed entity. I am expecting when I reattach the modified entity to the master EntityManager that a) the Partial entity will be replaced with a full entity and b) the EntityState would still be "Modified" and the OriginalValues hash map would still contain the list of changed properties. However, this isn't the case. The state of the entity in the master EntityManager is "Modified" but the originalValues has map is empty.

As a result, when I call SaveChanges() on the EntityManager, the FULL object is sent back to the server instead of just the changeset.

My question is why does calling detachEntity() (or indirectly _detach() method) clear the originalValues hash map?

Here is the breeze method that seems to be the culprit:

proto._detach = function () {
    this.entityGroup = null;
    this.entityManager = null;
    this.entityState = EntityState.Detached;
    this.originalValues = {}; // <!-- Why???
    this._validationErrors = {};
    this.hasValidationErrors = false;
    this.validationErrorsChanged.clear();
    this.propertyChanged.clear();
    };

Thanks so much

Answer 1

Good question. Why do we do that?

It's not wrong to clear it - detached is a strong signal that you no longer want to track the entity - but it isn't obvious that clearing is semantically necessary and it sure is inconvenient in your case.

I thought it might be to release references for GC. But I can't think of any refs in originalValues.

Nor is there much to be gained memory-wise by nulling originalValues.

It's possible that we were trying to clear the decks for a reattach. But that choice could be effected upon reattach based on the attach EntityState.

I don't know off the top of my head what breeze does with OV when you reattach as modified. Might or might not preserve it.

I'll let one of our architects weigh in.

Meanwhile, your scenario is kind of exotic and the workaround is pretty obvious, yes?