Shadow properties in NoTracking context

[igor-y]

Shadow properties may be used to read (and write) values from table columns that are not known at compile time. One very common scenario when this is useful is when your application allows defining extra fields for some entities.

However, if you at the same time want to take advantage of NoTracking mode of the ChangeTracker, you can't read values of shadow properties anymore since they are stored in ChangeTracker.

It would be nice to allow to explicitly specify that shadow properties should be loaded for detached entities as well. If that contradicts with the general design principles of EF then probably exposing some events when data is being read would solve the problem partially. It would then be possible to subscribe to such event and save values of shadow properties in some custom data structures.

[smitpatel]

Since those properties are shadow, you cannot hold them on your concrete model type. Where do you intend to store values of those property?

[igor-y]

@smitpatel as I wrote, I understand that storing these properties somewhere in the EF internal structures and allowing public access to them might contradict general principles of EF design. But exposing some events when data is being read from the database and making this raw data accessible there would allow us to subscribe to these events and read/store the shadow data ourselves into some data structures outside EF.

[ajcvickers]

@igor-y You can access shadow properties in any query, including no-tracking queries, by projecting and using the EF.Property method. For example:

context.Foos.AsNoTracking().Select(e => new
{
    Foo = e,
    MyShadowProp = EF.Property<string>(e, "MyShadowProp")
});

[igor-y]

@ajcvickers thank you, but that does not seem to be a solution of the problem. The code you shown as example requires knowledge of all defined shadow properties at compile time. But if that becomes known only at runtime, this code can't be used.

[ajcvickers]

@igor-y Can you explain a bit more why this won't work for properties known only at runtime? (Note that all shadow properties must be defined in the model. If you're looking for more dynamic properties than that, then this is being tracked by #2282.)

[igor-y]

@ajcvickers imagine that you have a method like GetAllUserDefinedEntityColumns() which returns an array of column names (and probably some other metadata), and then you need to select values for all these columns. How would you do that with the code above?

Regarding definition of the columns in the model. We may use separate context to implement GetAllUserDefinedEntityColumns() method, and build the primary context/model after we have read the metadata using this method.

Thank you for the link. Seems like what I need is something in between of Property Bags feature and Proper Dynamic Objects feature. Although, if implemented as described there each approach would entail certain overhead.

[ajcvickers]

@igor-y The query would need to be built dynamically using the same information used to build the model dynamically.

Triage: Closing this as a duplicate of #2282 since the request is for some form of dynamic model, which is covered by that issue in various ways.