0

Title pretty much says it all. If I have 2 classes:

public class Account
{
    public virtual Guid AccountId { get; set; }
    public virtual string Name { get; set; }
}

public class VendorAccount : Account
{
    public virtual string TaxId { get; set; }
}

How would I use a convention to create the VendorAccount table like so (or some approximation):

create table VendorAccount
(
    AccountId uuid not null primary key references Account (AccountId),
    TaxId varchar
);

I have been fussing at this for days. IJoinedSubclassConvention and ISubclassConvention do not allow you to specify the Id, and all other conventions can't seem to reach this situation either.

The closest I have gotten will make a column account_id, which is not what I want.

Jeremy Holovacs
  • 22,480
  • 33
  • 117
  • 254
  • Since you have a class hierarchy, are you using table per class hierarchy or table per subclass? – Russ Cam Feb 25 '13 at 22:46
  • @RussCam I am not clear on the difference, I guess. I am expecting the base class to have a table, and the subclass to have a table essentially "extending" the base class. – Jeremy Holovacs Feb 25 '13 at 22:49
  • Fluent NHibernate defaults to using table-per-subclass strategy - https://github.com/jagregory/fluent-nhibernate/wiki/Automapping-inheritance (see Configuring the subclassing strategy section) so you will have separate tables for `Account` and `VendorAccount`. You could provide some overrides to the automapping -https://github.com/jagregory/fluent-nhibernate/wiki/Auto-mapping or if you don't have that many entities, you could write the mappings for more control. – Russ Cam Feb 25 '13 at 22:53
  • Why does the primary key of `VendorAccount` need to reference the `AccountId` field (presumably the primary key) on `Account` i.e. what is the problem that you are trying to solve? There may be a better way of doing it with fluent NHibernate. Could you also post the mapping that you have so far? – Russ Cam Feb 25 '13 at 22:55
  • @RussCam From a database perspective, this is nice and efficient... the primary key of the subclass will always reference exactly one primary key on the parent class table. I had assumed that was how inheritance was supposed to work in NHibernate. – Jeremy Holovacs Feb 25 '13 at 22:58
  • I've never seen that kind of configuration in a class hierarchy (that's not to say it's not possible, however the relationship is inherited from a class perspective). It sounds like the table per class hierarchy might be a better fit for what you want to achieve. This means that there would be one table for both classes with fields for the properties of both classes and a discriminator field so that NHibernate knows which type to hydrate in the application when it gets a record. Does that sound like a better fit? – Russ Cam Feb 25 '13 at 23:02
  • @RussCam Hmmm... yes it does. I will look into this and see if this is what I really want to do. – Jeremy Holovacs Feb 25 '13 at 23:04
  • I think I understand where you are coming from - for a `VendorAccount`, you'd like to store the values for properties that are common with `Account` in the `Account` table and have a separate table for storing values for properties that are only relevant to `VendorAccount`. Is that correct? If so, I don't think this is *easily do-able* when there is inheritance relationship... – Russ Cam Feb 25 '13 at 23:09
  • @RussCam yes that is it exactly. – Jeremy Holovacs Feb 25 '13 at 23:13
  • Correction, *I don't think this is possible* when there is an inheritance relationship (you could split properties for a single type across tables, but the documentation discourages it - http://ayende.com/blog/2327/multi-table-entities-in-nhibernate) the `Account` table would still need a discriminator column to know whether a record represents an `Account` type or a `VendorAccount` type and then if it's a `VendorAccount` type to join to the `VendorAccount` table. – Russ Cam Feb 25 '13 at 23:16

0 Answers0