Columns in SELECT statements are reversed when entity class inherits from a base class

I’m using the 5.0.0-preview2.

Just noticed something weird, not really a bug but it is annoying when analyzing SQL queries…

When the entity type inherits from another type, the columns are reversed in the SELECTs, here’s what I mean:

    [Table(Name = "BsContact", IsColumnAttributeRequired = false)]
    public class Contact
    {
        [PrimaryKey]
        public int ContactId { get; set; }
        public string ContactCode { get; set; }
        public int? Age { get; set; }
        public DateTime? DateBirth { get; set; }
    }

generates this:

SELECT
        [t1].[ContactId],
        [t1].[ContactCode],
        [t1].[Age],
        [t1].[DateBirth]
FROM
        [BsContact] [t1]

but this mapping:

    public class BaseType
    {

    }

    [Table(Name = "BsContact", IsColumnAttributeRequired = false)]
    public class Contact : BaseType
    {
        [PrimaryKey]
        public int ContactId { get; set; }
        public string ContactCode { get; set; }
        public int? Age { get; set; }
        public DateTime? DateBirth { get; set; }
    }

generates this:

SELECT
        [t1].[DateBirth],
        [t1].[Age],
        [t1].[ContactCode],
        [t1].[ContactId]
FROM
        [BsContact] [t1]

Not really sure why it works with no base type, but the reverse order seems to originate from this method called by TypeAccessor<T>, it returns members in reverse order because it uses AddFirst and not AddLast. Is there any reason for that?

https://github.com/linq2db/linq2db/blob/0b8f1e08c173f12ab29d8d413e11f3bba3d4a476/Source/LinqToDB/Extensions/ReflectionExtensions.cs#L46

Thanks in advance

[jods4]

@guillaume86

Yes the deduping is for hidden by new members and is required, see:

Thanks for doing the research! If you modify the code, it’d be nice to leave a comment to explicit that purpose.

Sorry I’m not very familiar with the code base, what do you mean by “what we have in members already” ?

I was referring to the members local variable that contains all the public fields/properties of the type we’re looking at. My remark was meant to say that depending on the ordering we eventually land on, we don’t need those sorting shenanigans and we only need to filter out members hidden by new from GetMembers.

About sorting: it might be worth noting what MSDN says about GetMembers ordering anyway:

In .NET 6 and earlier versions, the GetMembers method does not return members in a particular order, such as alphabetical or declaration order. Your code must not depend on the order in which members are returned, because that order varies. However, starting with .NET 7, the ordering is deterministic based upon the metadata ordering in the assembly.

[MaceWindu]

Should be easy to fix. One of cases when tests-first works great. Just define hierarchy of test classes with properties, fields, new and interfaces and then define test over GetPublicInstanceValueMembers method for each hierarchy type and then make them work 😃