Modifiy XPO Session to Support Binary serialization

I have attached a solution that demonstrates that XPO objects CAN be serialized/deserialized. There is one problem:

When objects are deserialized, they get associated to to the default session (this is great), but the state of objects in incorrect. The demo shows that an object can be created, saved, serialized, deserialized and still have its proper Oid and OptimisticLockId, yet the object when deserialized is placed in an inner collection that essentially marks the object as new regardless of having a proper Oid and OptimisticLockId.

Proposed Solution:

I am suggesting that a helper method be created that simply transfers objects from the inner collection (state) that makes XPO 'think' they are new to the collection that makes XPO consider them 'loaded' if they have a valid Oid (I.e. -1 for an integer should remain new).

You can see from the Demo that developers attempting to use XPO in an N-Tier environent or anyone wanting the ability to serialize (store or transfer) XPO objects would love this feature.

NOTE: The OptimisticLockId is PERFECT to ensure data integrity (assuming the objects are always used with the same database or a developer knows what they are doing). The OptimisticLockId can also be serialized/deserialized and ensures that remote changes would fail on update if the data (in the database) had changed since the data was pulled (serialized) up to the moment of update.

Please, deeply consider this suggestion and also note that I would be very happy to be required to perform a cast to a base member to hide/protect this feature from abuse. Even an external helper would be great.

I imagine having access to a method related to a session such as:

session.ForceObjectsWithOIdsToLoadedState();

Is this possible? Please? Please?

Note without this feature, I am required to get the Oid of the object, fetch the latest copy (database version) of the object, manually check the OptimisticLockId, copy or transfer the properties to the newly loaded object and then perform a normal save>> where I have to still catch the possibility of a OptimisticLock failure. This makes coding ugly, majorly increases hits to the database, and significantly effects performance,let alone greatly increases the maintenance and complexity of designing objects and business logic.

TIA

Trevor