WHERE clause in generated SQL does not use ColumnAttribute.Name value

[wesfincher]

Given the following entity and column definition:

    [TableName("wcpEvent")]
    [PrimaryKey("EventId")]
    public class Event : EntityBase
    {
        [Column("EventId")]
        public override int Id { get; set; }
        // omitted
    }

and the following base class:

    public abstract class EntityBase
    {
        public virtual int Id { get; set; } 
        // omitted
    }

with the following Repository class

        private readonly IDatabase _context;
        public virtual T? SingleOrDefault(Expression<Func<T, bool>> filter)
        {
            return _context.Fetch(filter).SingleOrDefault();
        }

The following test fails:

        [TestMethod]
        public void Repository_SingleOrDefault_ShouldReturnNull()
        {
            using IUnitOfWork uow =
                new UnitOfWork(ConnectionString);
            var evt = uow.Repository<Event>().SingleOrDefault(e => e.Id == -1); // <-- Id vs EventId
            evt.Should().BeNull();
        }

The following exception is thrown:

Message: 
Test method DataServiceTest.RepositoryTests.Repository_SingleOrDefault_ShouldReturnOne threw exception:
System.Data.SqlClient.SqlException: Invalid column name 'Id'.

The SELECT clause is generated correctly. Expected behavior is for the WHERE clause to generate using the name of the property with ColumnAttribute.Name ('EventId')

[asherber]

@wesfincher What versions are you using of this library and StaTypPocoQueries?

[asherber]

Nevermind, I can reproduce. Looks like it has to do with the class being a descendant and the property being an override. I'll have to dig into this; I'm not sure whether the fix will be in this library, or PetaPoco, or StaTypPocoQueries.

[wesfincher]

Thank you for the quick response. And that's interesting, as I would expect the SELECT clause to face the same issue if that were the only cause. I tried stepping through code but wasn't able to identify a needed change in the short amount of time I had available. Thank you for looking into it!

…

On Fri, May 20, 2022, 9:18 PM Aaron Sherber ***@***.***> wrote: Nevermind, I can reproduce. Looks like it has to do with the class being a descendant and the property being an override. I'll have to dig into this; I'm not sure whether the fix will be in this library, or PetaPoco, or StaTypPocoQueries. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRRL3SZZOYAM7AA5OCCKZLVLA2VFANCNFSM5WQJ3HXQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[asherber]

The SELECT is generated by PetaPoco, using its normal mechanisms. The WHERE is generated when StaTypPocoQueries.Core grabs the MemberInfo for the field you're querying and passes it to this library to figure out the correct column name. The MemberInfo I get shows the DeclaringType as EntityBase, no references to Event, so when I ask PP to help me out with the column name, it's looking at EventBase. 

So I think the question is whether StaTypPocoQueries is able to pass me a MemberInfo that references the actual runtime class. I'll open a ticket over there.