mapping a deeper hierarchy

[Jan Limpens]

Hello,

I have this hierarchy

• Account
• Customer
• IndividualCustomer
• CorporateCustomer
• Administrator

All of them have properties to map. I do not know how to map the hierarchy for a single table / discriminator mapping.
Just make it flat:

• class
• subclass customer
• subclass individualcustomer
  

? Seems weird..

Any examples anywhere? Hints?

Thanks,

--
Jan

[Tuna Toksöz]

The doc?

http://www.hibernate.org/hib_docs/nhibernate/html/inheritance.html

just do subclass and add props as if it is a normal class?


Tuna Toksöz
http://tunatoksoz.com

Typos included to enhance the readers attention!

[Jan Limpens]

Hi tuna,

the docs are the first place I look, but they show only a one level deep hierarchy:

<class name="IPayment" table="PAYMENT">
    <id name="Id" type="Int64" column="PAYMENT_ID">

        <generator class="native"/>
    </id>
    <discriminator column="PAYMENT_TYPE" type="String"/>
    <property name="Amount" column="AMOUNT"/>

    ...
    <subclass name="CreditCardPayment" discriminator-value="CREDIT">
        ...
    </subclass>
    <subclass name="CashPayment" discriminator-value="CASH">

        ...
    </subclass>
    <subclass name="ChequePayment" discriminator-value="CHEQUE">
        ...
    </subclass>
</class>

so lets imagine, CreditCardPayment was abstract and I needed a MasterPayment, DinersPayment etc, and for the sake of the argument, they differ in a few props/cols. How would I map that? Put another subclass _into_ subclass? Or map it flat?

--
Jan

[Tuna Toksöz]

probably the former one. Try and let me know.

Tuna Toksöz
http://tunatoksoz.com

Typos included to enhance the readers attention!

[Jan Limpens]

What I did so far, was starting to map crom customer upwards (individual and corporate customer), this of course works and allowed me to refactor my app.

Now I have the need to retrieve [Accounts] from the db and still I cannot believe, that an abstract base class should be mapped discriminator based, I very much doubt it would work as well.

• abstract Account
• abstract Customer
• IndividualCustomer
• CorporateCustomer
• Administrator

like now I have this:

<class name="Customer" table="[User]" >
    <id name="Id">
      <generator class="identity" />
    </id>
    <discriminator column="Type" type="String" />
    <property name="PrimaryTelephone" />
            <column name="TelephoneOffice" />
    </property>
    <subclass discriminator-value="CorporateCustomer"></subclass>
    <subclass discriminator-value="IndividualCustomer"></subclass>
</class>

I have trouble imaginating that this would work:

<class name="Account" table="[User]" >
    <id name="Id">
      <generator class="identity" />
    </id>
    <discriminator column="Type" type="String" />
    <subclass discriminator-value="Customer">
        <property name="PrimaryTelephone" />
            <column name="TelephoneOffice" />
        </property>
    </subclass>
    <subclass discriminator-value="CorporateCustomer"></subclass>
    <subclass discriminator-value="IndividualCustomer"></subclass>
</class>

It's kind of non-sensical to put a discriminator for an abstract class mapping, there will never be a direct instance of Customer. It looks just wrong to map it that way.

Putting another discriminator into the Customer subclass already violates the mapping schema, so I am pretty positive, that trying to hack that together would be a waste of time.

Nobody ever came in contact with such a situation? How can I come around this?

--
Jan

[Humberto Marchezi]

Hi Jan,

I think the solution also depends on what kind of data modeling you are using for your hierarchy:
it is one table for the entire hierarchy or one table per class ?

Usually I use one table per class strategy and I don´t have problems mapping deeper hierarchies with <joined-subclass>.

--
Humberto C Marchezi
---------------------------------------------------------
Master in Electrical Engineering - Automation
Software Consultant and Developer
at the Town Hall of Vitória

[Jan Limpens]

Yip, I was under that impression, too, but I wanted to use that stategy as a last ressort.

what I did in the end, was
have Account implement IAccount
Customer _has_ an Account
Custumer implements IAccount, too, proxying the Account property.

same goes for other types of Accounts.

works quite ok.

--
Jan