Hello,

Regarding objects in the Context, the manual mentions that:

If an entity is already loaded in the used Context object, the entity data is not added to a new entity object, but the entity object already loaded is updated.

However, when I do something like:

            _Context.Add(entityToFetch);

            IEntity2 e = GetMoreDetailedVersionOf(entityToFetch)

            _Context.Add(e);
            e = _Context.Get(e);

EntityToFetch has a m:n collection which is empty. The more detailed version of entityToFetch, called 'e' comes with this collection filled. But when 'e' is added to the context, the collection is not updated in the already-in-the-context-entityToFetch (as I would have expected from the manual line above). It ends up with e being still with an empty collection, although the collection itself is added to the context.

Did I miss something or is this by design? Thanks, Colin

PS: I am using the Context on the client, after deserialization from a wcf webservice.

This is a known limitation of v2.x

I've had to implement my own entity merging logic to get around it. Frans has indicated that in version 3.x there "may" be improvement to the context including perhaps an IContext interface and hooks were we could provide our own merging and field value conflict resolution.

It would be good if we could see a more firm list of v3.0 features.

With respect to m:n relations: when fetched they're a snapshot on a state, as they always require an intermediate entity which is still in the DB. If that entity changes, the m:n relationship changes too, these aren't kept in sync in memory nor will this be done in the future, this is the reason why m:n relations are readonly.

About graph merging, in v3 we'll look again at the Context and where to make it better as currently the usage is a bit cumbersome (also for example to get an entity and subgraph OUT of the context).

About a list of features: we won't disclose this, though we do hope to fix as many open roadblocks as possible for v3, if not through code directly, then at least through creating extension points so you can add the code yourself with ease (for example if the particular issue is an edge case)

Thank you both for your help. OK, I think I will try to do my own merging by replacing/completing empty/partially empty collections with fresh additional data. I guess one of the trick I should be careful of is that the dependent data (the entities within the collections of the new entity - newE) should also update their back reference, from newE to the contexted version of newE... To systematically update each newly retrieved data, I will need the list of such entities, and I guess I can use the ObjectGraphUtils class for that. Also, regarding m:n collections, I understand I won't be able to add/remove elements if they are read-only, and should therefore get and update the intermediate, associative entity instead... Regards, Colin