Skip to content
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

Decide how data annotations on fields should work #6267

Closed
ajcvickers opened this issue Aug 8, 2016 · 1 comment
Closed

Decide how data annotations on fields should work #6267

ajcvickers opened this issue Aug 8, 2016 · 1 comment

Comments

@ajcvickers
Copy link
Member

Currently data annotations on fields are used if and only if the field is mapped and has no property associated. For example, the Key attribute will be applied in this case:

public class Foo
{
    [Key]
    private int _key;
}

assuming _key is a mapped field:

builder.Entity<Foo>().Property("_key");

The data annotation will not be applied in this case:

public class Foo
{
    [Key]
    private int _key;

    public int Key => _key;
}

It is instead expected that the data annotation will be taken from the property.

If we decide to allow data annotations to be applied to fields that have associated properties, then we also need to decide what to do when the field and the property have conflicting annotations:

public class Foo
{
    [Column("KEY")]
    private int _key;

    [Column("ID")]
    public int Key => _key;
}
@divega
Copy link
Contributor

divega commented Aug 8, 2016

We like it the way @ajcvickers implemented it, e.g. an annotation on the property always override the one on the field.

@divega divega closed this as completed Aug 8, 2016
@divega divega added this to the 1.1.0 milestone Aug 8, 2016
ajcvickers added a commit that referenced this issue Aug 8, 2016
Issues #4357, #4855

This change adds fluent and lower-level APIs to set backing fields or properties with no fields as well as conventions for using the fields and a mechanism to provide control over when the property is used and when the field is used.

Also see #6266, #6267, and #6268.
ajcvickers added a commit that referenced this issue Aug 8, 2016
Issues #4357, #4855

This change adds fluent and lower-level APIs to set backing fields or properties with no fields as well as conventions for using the fields and a mechanism to provide control over when the property is used and when the field is used.

Also see #6266, #6267, and #6268.
ajcvickers added a commit that referenced this issue Aug 8, 2016
Issues #4357, #4855

This change adds fluent and lower-level APIs to set backing fields or properties with no fields as well as conventions for using the fields and a mechanism to provide control over when the property is used and when the field is used.

Also see #6266, #6267, and #6268.
ajcvickers added a commit that referenced this issue Aug 10, 2016
Issues #4357, #4855

This change adds fluent and lower-level APIs to set backing fields or properties with no fields as well as conventions for using the fields and a mechanism to provide control over when the property is used and when the field is used.

Also see #6266, #6267, and #6268.
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Oct 15, 2022
@ajcvickers ajcvickers modified the milestones: 1.1.0-preview1, 1.1.0 Oct 15, 2022
@ajcvickers ajcvickers added type-unknown and removed closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-unknown labels Oct 15, 2022
@ajcvickers ajcvickers removed this from the 1.1.0 milestone Oct 18, 2022
@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants