I've just spent a lot of time working out why a common routine worked in some cases and not in others.

Turns out that DoNotPerformAddIfPresent was True in one case but not the other.

The documention re. this property is slightly misleading: The breaking changes for v2.0 and v2.6 are quite clear that it is False by default

The best practises seems out of date since it hints that the property is True by default and suggests turning it off for faster bulk addition. It also mentions that FetchEntityCollection() sets it to False.

In my case, I don't specficially set it True anywhere but it gets set to True when a ContextToUse is set on a query (EntityQuery if that is relevant)

Could you please update the docs to reflect this.

Cheers Simon

Please provide the LLBLGen's runtime library version, and a code snippet.

v3.5 Final

No snippet - this is a documentation request.

It is indeed set to true only when the collection's ActiveContext property is set to a value. This to avoid mitigating the context.

We'll correct the best practices docs to make it become in-sync. This property isn't documented with its own section I think, but I think it could be added to the context section as a note.

This might be an aside or it might be worthy of a mention in the Context docs if you are updating them anyway:

Those of use who use the whole entity graph (cloning, finding types within the graph etc.) and especially using ReferencedEntityMap may have assumed that any entity within the graph can be used as the root object and all other entities within the graph will be found.

It turns out this isn't necessarily the case unless a Context was used in the original query. If it wasn't then it is possible that ReferenceEntityMap will only find a subsection of the full entity graph.

Example: A ClientFileEntity 1:m with ClientEntity each of which has an intermediate m:n table pointing to multiple PolicyEntity (plus other various paths).

A ReferencedEntityMap created from the top-level ClientFileEntity gave 23 distinct entity types and located 138 entities. But a ReferencedEntityMap created from a single PolicyEntity gave 8 distinct Entity types and located just 39 entities (none of which were the top-level ClientFileEntity I needed)

Putting a Context back onto the original query sorted the issue. You have no idea of the panic this caused me thinking my understanding of entity graphs was wrong!

Cheers Simon

simmotech wrote:

This might be an aside or it might be worthy of a mention in the Context docs if you are updating them anyway:

Those of use who use the whole entity graph (cloning, finding types within the graph etc.) and especially using ReferencedEntityMap may have assumed that any entity within the graph can be used as the root object and all other entities within the graph will be found.

It turns out this isn't necessarily the case unless a Context was used in the original query. If it wasn't then it is possible that ReferenceEntityMap will only find a subsection of the full entity graph.

I had to look up what you meant with ReferencedEntityMap, looks like a class from the fastserialization code, correct? If you use the object graph utils, every entity in the graph can be used as 'root' as it's not a tree, but a graph, unless you have relationships which are one-sided.

ReferencedEntityMap is IMHO used for different purposes: it's a place holder for a reference made multiple times, so you serialize the entity just once. The object graph utils use the objectid to find multiple references, but have the advantage to traverse the complete graph from any entity in the graph (unless, of course there's a 1 sided relationship, which is only traversable from A to B and not from B to A) to any other entity in the graph