-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use parameterized constructors to generate default mapping of properties #4356
Open
Tracked by
#22952
Milestone
Comments
divega
changed the title
Alternate "map all fields" discovery strategy
Consider having alternate "map all fields" discovery strategy
Jan 21, 2016
This could be a different convention: #214 |
ajcvickers
changed the title
Consider having alternate "map all fields" discovery strategy
Consider alternate property discovery convention(s)
Feb 26, 2018
Use of parameterized constructors also provides more information that could be used to generate default mapping of properties. |
@divega This isn't currently in 3.0. |
@ajcvickers Thanks. I have updated the description of this issue with the option to map no properties by convention. |
73 tasks
ajcvickers
changed the title
Consider alternate property discovery convention(s)
Use parameterized constructors to generate default mapping of properties
Oct 27, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Per #4314 by convention in RTM we will only discover properties that have public getters and public or non-public setters (with the exception of collection navigation properties which don't need setters).
This issue is about the idea of having an alternate conventions for property mapping. One example is "map all fields" discovery convention that users can opt into and which emphasizes persisting all the possible state of an entity (i.e. all fields) regardless of whether they are exposed as properties.
E.g. code like this:
This would enable a class like this to produce a table with Id, Name and BirthDate:
Another example would be a "null" property discovery convention that maps no properties by convention but allows them to be configured explicitly. This was requested in #14405.
Note that property discovery conventions interact with other logic, e.g. to figure out if a property should be considered scalar, navigation and to potentially bring other types into the model so it is not easy to simply write code that iterates over all fields using reflection. It is also not possible currently to create a property that in the CLR type is backed by a field but not associated to an actual CLR property.
The text was updated successfully, but these errors were encountered: