Controlling TPH mapping

Hello,

Consider the following class hierarchy:

public abstract Resource : Entity<long>
{
    /* implement CreatedOn, UpdatedOn */
}

public abstract SecurableResource : Resource
{
    /* properties related to security */
}

public sealed Product : SecurableResource
{
    /* properties related to products */
}

public sealed User : SecurableResource
{
    /* properties related to products */
}

I have implemented Resource and SecurableResource to share implementations and was never intended to be tables. However, LightSpeed wants to use a table "resources". How do I'd like to indicate to LightSpeed that Product and User are "root" entity types, however the properties such as CreatedOn etc defined in Resource should also exists in the "products" and "users" table. I have no plan to create queries related to "Resource" or "SecurableResource" base types.

Thanks, Werner

You will want to use concrete table inheritance for this.

e.g. In the designer add Resource, SecurableResource, Product and User as entities.

• Turn on CreatedOn/UpdatedOn on Resource
• Set the Inheritance option on Resource to "Abstract"
• Add your additional properties to SecurableResource
• Set the Inheritance option on SecurableResource to "Abstract"
• Set up an inheritance relationship between SecurableResource and Resource and mark that as ConcreteTableInheritance
• Add your additional properties to Product and User
• Set up inheritance relationships between Product and SecurableResource and User and SecurableResource, mark both of these as ConcreteTableInheritance

If you now sync with the database it should create 2 tables - Product and User and include all of the underlying properties in Resource and SecurableResource. Queries against these will use Product and User as the tables for access.

Jeremy

Thanks Jeremy.

Following this process, there is a bug in the designer when you create a migration. While the "Up" method creates the correct tables, the "Down" method also wants to delete the abstract tables.

Werner

I don't really use the designer that much. When I look at the source, I see no difference except that the UnitOfWork doesn't have queries for the abstract type. However, almost all code I write is against IUnitOfWork and LightSpeedContext.

How does this work behind the scenes? I ask the question so that I can avoid problems.

Thanks, Werner

Unfortunately there seems to be a problem. Using the designer, I created an entity called "Resource" and another called "Sample" and followed the instructions such that Sample inherits from Resource. Resource has CreatedOn, UpdatedOn, LockVersion etc. Sample has "Name". When I try to insert a "Sample" the following statement is generated, which is clearly incorrect.

INSERT INTO Sample
(
  Id,
  CreatedOn,
  DeletedOn,
  LockVersion,
  UpdatedOn,
  CreatedOn,
  DeletedOn,
  LockVersion,
  Name,
  UpdatedOn
)
VALUES
(
  21,
  '1/1/0001 00:00:00',
  NULL,
  0,
  '1/1/0001 00:00:00',
  '4/5/2012 02:46:47',
  NULL,
  0,
  'test',
  '4/5/2012 02:46:47'
)

I'm using MySQL 5.

Werner

ConcreteTableInheritance is defined as inheriting from a base class which is not Entity (but somewhere down the chain it will eventually inherit from Entity) and where you dont have the Discriminator attribute applied. So if you are avoiding the designer then you just need to define this as a standard inheritance structure minus the Discriminator attribute on your root entities.

I will have a look into the migration issue - thanks for alerting us to this :)

Jeremy

What does your model code look like? Im not seeing this behavior on the example here which I set up yesterday.

Jeremy

Here is the model:

 [Serializable]
  [System.CodeDom.Compiler.GeneratedCode("LightSpeedModelGenerator", "1.0.0.0")]
  [System.ComponentModel.DataObject]
  public abstract partial class Resource : Entity<long>
  {
    #region Fields


    #pragma warning disable 649  // "Field is never assigned to" - LightSpeed assigns these fields internally
    private readonly int _lockVersion;
    private readonly System.DateTime _createdOn;
    private readonly System.DateTime _updatedOn;
    private readonly System.Nullable<System.DateTime> _deletedOn;
    #pragma warning restore 649    

    #endregion

    #region Field attribute and view names



    #endregion

    #region Properties



    /// <summary>Gets the row version number for concurrency checking</summary>
    [System.Diagnostics.DebuggerNonUserCode]
    public int LockVersion
    {
      get { return _lockVersion; }   
    }

    /// <summary>Gets the time the entity was created</summary>
    [System.Diagnostics.DebuggerNonUserCode]
    public System.DateTime CreatedOn
    {
      get { return _createdOn; }   
    }

    /// <summary>Gets the time the entity was last updated</summary>
    [System.Diagnostics.DebuggerNonUserCode]
    public System.DateTime UpdatedOn
    {
      get { return _updatedOn; }   
    }

    /// <summary>Gets the time the entity was soft-deleted</summary>
    [System.Diagnostics.DebuggerNonUserCode]
    public System.Nullable<System.DateTime> DeletedOn
    {
      get { return _deletedOn; }   
    }

    #endregion
  }


  [Serializable]
  [System.CodeDom.Compiler.GeneratedCode("LightSpeedModelGenerator", "1.0.0.0")]
  [System.ComponentModel.DataObject]
  public partial class Sample : Resource
  {
    #region Fields

    [ValidateLength(0, 255)]
    private string _name;

    #pragma warning disable 649  // "Field is never assigned to" - LightSpeed assigns these fields internally
    private readonly int _lockVersion;
    private readonly System.DateTime _createdOn;
    private readonly System.DateTime _updatedOn;
    private readonly System.Nullable<System.DateTime> _deletedOn;
    #pragma warning restore 649    

    #endregion

    #region Field attribute and view names

    /// <summary>Identifies the Name entity attribute.</summary>
    public const string NameField = "Name";


    #endregion

    #region Properties



    [System.Diagnostics.DebuggerNonUserCode]
    public string Name
    {
      get { return Get(ref _name, "Name"); }
      set { Set(ref _name, value, "Name"); }
    }
    /// <summary>Gets the row version number for concurrency checking</summary>
    [System.Diagnostics.DebuggerNonUserCode]
    public int LockVersion
    {
      get { return _lockVersion; }   
    }

    /// <summary>Gets the time the entity was created</summary>
    [System.Diagnostics.DebuggerNonUserCode]
    public System.DateTime CreatedOn
    {
      get { return _createdOn; }   
    }

    /// <summary>Gets the time the entity was last updated</summary>
    [System.Diagnostics.DebuggerNonUserCode]
    public System.DateTime UpdatedOn
    {
      get { return _updatedOn; }   
    }

    /// <summary>Gets the time the entity was soft-deleted</summary>
    [System.Diagnostics.DebuggerNonUserCode]
    public System.Nullable<System.DateTime> DeletedOn
    {
      get { return _deletedOn; }   
    }

    #endregion
  }




  /// <summary>
  /// Provides a strong-typed unit of work for working with the LightSpeedModel1 model.
  /// </summary>
  [System.CodeDom.Compiler.GeneratedCode("LightSpeedModelGenerator", "1.0.0.0")]
  public partial class LightSpeedModel1UnitOfWork : Mindscape.LightSpeed.UnitOfWork
  {

    public System.Linq.IQueryable<Sample> Samples
    {
      get { return this.Query<Sample>(); }
    }

  }

The fields are defined on both the base class and the derived class, you should delete these off the derived class (assuming these are a concern you want covered by the base class).

Jeremy

Mmm, it seems that the designer isn't intelligent enough to figure out that the hierarchy already contains those fields. So whenever you add a new entity, the default policy is applied, and when you configure the inheritance, it doesn't ignore any policies set on the subclasses. However, if I use SingleTableInheritance, those properties are ignored.

I assume this may be another bug that I was unaware of.

Werner

Yep thats right, the designer doesn't try and detect these kinds of issues. The defaults policy isn't actually persisted against an entity after it has been created on the design surface so this isn't something that is considered when configuring inheritance. STI behaves differently because the base classes are considered for mapping where as with Concrete Table Inheritance we just import the fields verbatim on the basis that you have implemented it as you want it to behave so likely something we could look at improving on there in terms of designer warnings.

Jeremy