Optmizing JOIN clauses by removing references to abstract types

[Catalin]

Hi,

let's take a simple example mapped with flat inheritance:

public abstract class Animal
  {
    public int Id { get; set; }
    public string Name { get; set; }
    public Home Home { get; set; }
  }

  public class Dog : Animal
  {
    public int Age { get; set; }
  }

  public class Cat : Animal
  {
    public int Lives { get; set; }
  }

  public class Home
  {
    public int Id { get; set; }
    public string Name { get; set; }
    public Home() { Animals = new List<Animal>(); }
    public IList<Animal> Animals { get; set; }
  }

 

For accessing the property home.Animals the generated SQL statement would be:

SELECT b.[Id] COL1, b.[voa_class] COL2, b.[HomeId] COL3, b.[nme] COL4, b.[Lives] COL5, b.[Age] COL6
FROM [Home] a LEFT JOIN [Animal] AS b
  ON (a.[Id] = b.[HomeId] AND (b.[voa_class] IN ('Animal', 'Dog', 'Cat')))
WHERE a.[Id] = @p0

 

Here is something I don't understand. Why is the 'Animal' appearing in the JOIN clause?

The Animal class is abstract which means there will never be any objects of that type. Indeed in the table there are no other entries but 'Dog' and'Cat'.

I think the ORM should optimize the statement by removing the abstract types from the JOIN clauses.

 

[Boris Georgiev]

Hello Catalin,

When you are using Flat inheritance, Telerik Data Access will generate only one table for all of the classes which are part of the inheritance and the table will be for the base class. This is why you are seeing the Animal table in the join clause. For more information about Inheritance please refer to this article: http://docs.telerik.com/data-access/developers-guide/code-only-mapping/inheritance/fluent-mapping-inheritance-overview.

I hope that helps.

Regards,
Boris Georgiev
Telerik

 

[Catalin]

Hi Boris,

I actually mind the string 'Animal' in the IN enumeration by the ON expression.

Regards,
Catalin

[Viktor Zhivkov]

Hello Catalin,

Thank you for your feedback.
This is a nice suggestion for optimization, but I am curious if you are seeing any (significant) performance penalty because of the extra join clause.
As far as I know there is no way to explicitly tell our mapping that a class is an abstract one so I guess this is the reason why we are adding it together with all derived ones.
If we are able to optimize our LINQ translation in the recommended way I will make sure to contact you back.

Regards,
Viktor Zhivkov
Telerik