PropertyAccessMode enhancement

[jdcrutchley]

Could PropertyAccessMode have an additional option, possibly called IgnoreDuringConstruction, which would tell EF to create the property, use it's public getter when storing to the database for query reasons, but when instantiating from the database, just ignore it. The use case for this would be having getter-only properties computed from other properties, which can be easily queried at the database with Linq, without the need to do this:

private int _myProperty; public int MyProperty { get { return Number1 + Number2; } private set { } }

The above works fine, but adds junk to the object that serves no useful purpose other than to trick EF into not doing anything to set the property.

[ajcvickers]

@jdcrutchley Just want to clarify something. You said, "trick EF into not doing anything to set the property." I don't see anything in that property definition that will prevent EF from setting the property. Can you elaborate more?

That being said, the idea of computed properties that are persisted for query is interesting. We will discuss. 😸

[jdcrutchley]

I probably worded that badly. My understanding was, it'll find the field _myProperty, which isn't actually used for anything, and set that. I have the private set only so that EF will pick up the property in the first place without having to do anything special in the mapping. However, now that I think about it more, I probably don't need the field since a do-nothing setter serves the same purpose. I'll try that out.

Maybe just close this, since the only way I can think of to make this nicer is to have EF automatically make a property for any public getters it finds, and if there's no setter just ignore it during construction. My perfect scenario would be to have a public get-only method, EF picks that up as a property and stores the value in the database so it can be easily queried, and just ignores it when reconstructing the objects. That may mess up other expected behaviors for other folks though.

[ajcvickers]

We discussed this in triage and decided that as this time having no field and an empty setter is a reasonable solution for his mapping, which is not something commonly asked for.

[daniel-jann]

Tried this in 3.1.1 and when adding a new entity to the DbContext, I got the exception "Unable to track an entity of type 'MyEntity.MyProperty#MyType' because primary key property 'KeyField1' is null." I should mention MyProperty is the calculated field and it is an Owned type and I got a composite key (KeyField1, KeyField2) on MyEntity. As soon as I make MyProperty a regular { get; set; } one, the problem goes away...

[ajcvickers]

@daniel-jann Please open a new issue and post a small, runnable project or complete code listing that reproduces the behavior you are seeing so that we can investigate.