Skip to content

Attributes derived from IgnoreAttribute are ignored #558

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

Closed
leonluc-dev opened this issue Jun 9, 2017 · 5 comments
Closed

Attributes derived from IgnoreAttribute are ignored #558

leonluc-dev opened this issue Jun 9, 2017 · 5 comments
Assignees
Labels

Comments

@leonluc-dev
Copy link
Contributor

leonluc-dev commented Jun 9, 2017

Since version 1.3.3 of the library there has been an issue with using attributes that derive from IgnoreAttribute.

The following example works fine:

[Table]
public class Person
{
      //......
      [Ignore]
      public string Name { get; set; }
}

The following example fails (Name is still added to the table):

[AttributeUsage(AttributeTargets.Property, AllowMultiple = false, Inherited = true)]
public class MyIgnoreAttribute : IgnoreAttribute
{
           
}

[Table]
public class Person
{
      
     //....

      [MyIgnore]
      public string Name { get; set; }
}

Could this be a issue with the new reflection API used in the library?

@leonluc-dev
Copy link
Contributor Author

leonluc-dev commented Jun 9, 2017

Found the culprit of this issue.

SQLite.cs, Line 1889:
var ignore = p.CustomAttributes.Any(x => x.AttributeType == typeof(IgnoreAttribute));

This kind of check only checks for the IgnoreAttribute itself, but not for attributes derived from IgnoreAttribute

Changing this line to the following solves the issue.

var ignore = p.IsDefined(typeof(IgnoreAttribute),true);

IsDefined also takes derived types into account.

I have created a pull request for this issue: #559

@hvaughan3
Copy link

@praeclarum @gameleon-dev
Possibly related to my post here?

@praeclarum
Copy link
Owner

Thanks for catching this. Working on a test now...

@praeclarum praeclarum added the Bug label Aug 1, 2017
@praeclarum praeclarum self-assigned this Aug 1, 2017
@leonluc-dev
Copy link
Contributor Author

@praeclarum @hvaughan3

That seems related to this issue, yes. I verified it in my code and it seems the already merged pull request #559 solves issues like #549 as well.

praeclarum added a commit that referenced this issue Aug 1, 2017
@praeclarum
Copy link
Owner

Thanks! I added a test so hopefully won't regress on this again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants