Search code examples
databaselinqpad

What information does LINQPad use to generate Association attributes/Navigation Properties?

I'm connecting to a SQL Server database using LINQPad, which then generates a TypedDataContext.

In an old version of the database, tables (which are not generated through ASP.NET C# code) have navigational properties to other tables.

In the new version a team have developed, there are no navigational properties.

My first instinct was that there were missing constraints, which turned out to be true. After a developer added the foreign key constraints to the table, there were still no navigational properties.

Using ILSpy for LINQPad, I reflected on the type represented in the table, and found that in one object there were properties with Association attributes:

[XmlIgnore]
[Association(Name = "FK_AvailabilityActivity_SFT_WK_Shift", Storage = "_Ds_Shift", ThisKey = "SFT_WK,SFT_WK", OtherKey = "SFT_WK,SFT_WK", IsForeignKey = true)]
public Ds_Shift Ds_Shift
{
    get
    {
        //Error decoding local variables: Signature type sequence must have at least one element.
        return _Ds_Shift.Entity;
    }
    set
    {
        //Error decoding local variables: Signature type sequence must have at least one element.
        _Ds_Shift.Entity = value;
    }
}

And the other, new object does not.

So, my question is:

What information does LINQPad use to generate these properties?

Once I know this, I should be able to add that information and query across tables using navigation properties.

Solution

  • According to Joe Albahari (author of LINQPad):

    It just reads the foreign key constraints and builds it from that. Sometimes it's unable to infer a name for an association, or the name is duplicated in another association or property, but that's quite rare.

    So my suspicion that there were missing constraints was right, it just so happened that when the developer added the missing constraints, the table's primary key was left out (due to another column having a clustered index, which SQL Server attempts to create by default when you assign a primary key, which we solved by using the NONCLUSTERED keyword).