Inheritance Mapping Problem

brunocosta · **Joined:** Fri Apr 01, 2005 2:33 pm **Posts:** 3

Hibernate version: 2.1.7

Name and version of the database you are using: MySQL 4.1.10

I have the following class hierarchy: Person <- Company, and Person <- Salesman, and I have them mapped in Hibernate using table per subclass. One record of the Person table may represent (at the same time) a Company and a Salesman.

The problem is that Hibernate cannot insert a Salesman when there is already a Company and vice-versa. Is there any way in Hibernate of reusing the same record (id) of the Person table to both subclasses?

Thank you in advance.

brunocosta · **Joined:** Fri Apr 01, 2005 2:33 pm **Posts:** 3

Anyone? =(

DyslexicMonkey · **Joined:** Tue Apr 19, 2005 11:24 am **Posts:** 8

Is there any reason why you cannot have: Person <- Company <- Salesman ? It sounds more of an issue of class hierarchy than it does a hibernate problem. If you were to setup the hierarchy in the fashion described above I do not believe you should encounter a problem.

brunocosta · **Joined:** Fri Apr 01, 2005 2:33 pm **Posts:** 3

Sorry, but you quite not understand what my problem is. A Salesman and a Company normally have different characteristics, but should share few and common properties, so there is no issue with my class hierarchy (Person <- Company, Person <- Salesman), but with the last classes on the hierarchy (Company, Salesman) sharing the same id of the root class (Person).

Hibernate seems not to have a way of doing this in a "clean" manner. When I try to insert a Company with the same id as an already recorded Salesman, Hibernate tries to update Company and Person, and not just an insertion of a Company.

DyslexicMonkey · **Joined:** Tue Apr 19, 2005 11:24 am **Posts:** 8

Quote:

A Salesman and a Company normally have different characteristics, but should share few and common properties...

This implies to me that you need to introduce an abstract class that contains the common properties to both Company and Salesman (otherwise you are just duplicating code and possibly database entries). So something along the lines of Person <- AbstractSalesThing <- Company and Person <- AbstractSalesThing <- Salesman. This may help somewhat.

However, I'm sure that I am ignoring the true problem at hand, and that may be due to fully understanding your problem. I don't see why you would want to have a Company with the same identification of a Salesman. If I am interpreting your problem, a Salesman should belong to a Company. Then, inheritance should not be used, and rather delegation.

This would appear something like the following:

Code:

public class Salesman extends Person {
    private Company company;
    public Company getCompany() { return company; }
    public void setCompany(Company value) { company = value; }
    ...
}

If that still does not try to answer your question(s), then please articulate more. As much as I would like to be able to read minds, it's just not possible (at least for me).

axcosta · **Posted:** Thu Apr 21, 2005 9:36 am

Dear Dyslexic,

Do not try to interpretate our problem (I work at the same company as the guy who started this topic), at your own manner. Just follow its description and try to understand. If you could help, I´d be very grateful.

We have used a fictious example (Person, Company, Salesman), but we could also state the class hierarchy we have as A <- B, A <- C, or, B extends A, and C extends A; being A, B, C different types of classes (obviously).

Repeating ourselves extensively for the sake of clarifying the problem, we want that B and C instances of the their respective classes to share the same ID as an instance of A. Or, in another way, we really need that common properties of B and C classes to be stored in a more generalized class (A), so we could (if we need) treat the whole bunch of B and C objects as A objects (with that restrict few and common properties). If that´s not clear enough, please complain.

It happens (the problem!) that we could not find a way in Hibernate to do that type of thing in a clean manner. If there´s already A and B objects (same ID), and we want to insert a C object to share that ID, Hibernate does not allow us to do that (or, of course, we are not knowing how we could tell Hibernate how to do that!).

Sincerely,
Andre.

keule · **Posted:** Thu Apr 21, 2005 9:51 am

How do you do that in Java? A <- B, A <- C, then first cast an A as a B then cast A as a C??? I think you should really do it that way: Make B and C contain an A. If thats not enoug, make an Interface with the Methods of A und make A and B implement it.

keule · **Posted:** Thu Apr 21, 2005 9:53 am

Quote:

If thats not enoug, make an Interface with the Methods of A und make A and B implement it.

should be: If thats not enough, make an Interface with the Methods of A und make A and C implement it.

DyslexicMonkey · **Joined:** Tue Apr 19, 2005 11:24 am **Posts:** 8

The only advice that I could give is that you have a foreign key that points to the same identification. The primary key for a Company and Salesman will have to be different (from what I have experienced thus far...and I could be wrong). I can't make you accept my suggestions because there may be a certain reason why you are doing things a certain way.

Good Luck.

axcosta · **Posted:** Thu Apr 21, 2005 3:58 pm

Keule and Monkey,

Imagine that you have a Sales application where you have to sell/buy products (any type of goods). There you store not only your salesmen, but also the eventual customers you shoud have (to send them newsletters or any other kind of information, for example). So far, you should have a Salesman class and a Customer class. And at the most of it, they will store different people (thence, different data).

Imagine now that one of your salesmen is buying goods and the application user is wondering if your system is capable of retrieving information about that salesman and just complete the remainder for the customer/salesman. How would you model that?

The simple way is of course having two distinct classes, and if the case that I just mentioned happens, the system user would just create a new customer with the same (common) data as the salesmen. They would exist twice in your database, even though they are the same person.

What did we imagine? We have a Person class, and a Customer and Salesmen that extends that superclass. And when there is a Customer that is also a Salesman, we would just use the same identification (and other common data) of the Salesman, and create that Customer.

Thank you again for you valuable time!

Andre

keule · **Posted:** Fri Apr 22, 2005 4:18 am

Sorry for my clumsy writing above...
I don't think that your solution is possible. I thinks it's illegal in Java. What should Hibernate return when you make a query against the super class? Instances of Customer or instances of Salesman? If you would make a query against Customer and one against Salesman you would suddenly hafe two different objects that mean the same.

I would it try to...

Merge the two classes

If that's not possible (too much empty columns etc.) Make a seperate class like BusinessPartnerInformation and store there the shared information. Make a reference from both classes Salesman/Customer to that one.

Now if your system wants to create a new Customer, search the db for a corespondig Salesman/BusinessPartnerInformation and link it to the BusinessPartnerInformation.

Weelink · **Posted:** Fri Apr 22, 2005 5:04 am

I had the same problem. I searched the forum and this topic didn't show up in the first 50 results (probably wrong keywords ;)), so I started an other topic (http://forum.hibernate.org/viewtopic.php?t=941431). But I did find a solution.

First I add the Person-object

Code:

session.save(person);

After that I evict the person out of the session:

Code:

session.evict(person);

I manually added a record to the database for the Company and the Salesman:

Code:

insert into company values(personId, ...);
insert into salesman values(personId, ...);

Then I clear the session, set the relationId, find the Company, set the values and update the object:

Code:

session.clear();
company.setPersonId(person.getPersonId());
companyDAO.findByExample(company); // data access object, a session.find will probably have the same result
company.setXXX(xxx);
session.update(company);

keule · **Posted:** Fri Apr 22, 2005 5:18 am

Sorry, I just think this is wrong/illegal oo-modeling. You can't have an Object which is an instance of multiple classes! I think you will run into problems with your solution. But anyway, if it's fine for you...

DyslexicMonkey · **Joined:** Tue Apr 19, 2005 11:24 am **Posts:** 8

I agree whole-heartedly with keule, and you will only find problems with your current model if you stick with it. Chances are you will sometime want to refactor your code to reflect the changes desired by your users, and having the same id point to two separate objects will just cause problems.

I would highly suggest using either a common interface (or abstract class), or just have one of the classes be a delegate in the other.

If you decide to stick with your current model then that's fine. It's your project. We can't make you do something one way or another.

Weelink · **Posted:** Fri Apr 22, 2005 9:34 am

We have the following situation:

The user adds a customer who has a postal address in Hawaii. He also adds a distributor who has a postal address in Hawaii.

The user wants to send an offer to all the relations in Hawaii, i.e. the customer and the distributor. Existing customers are getting a discount and new customers must pay the whole price. So when we want to get all the relations in the database, we also need to know if someone is a customer or not.

Am I understanding you correctly, when I assume that we have the following diagram:

Code:

                  <<interface>>
           +-------------------------+
           +        IRelation        +
           +=========================+
           + getRelation(): Relation +
           +-------------------------+
                        ^
     +------------------+------------------+
     |                                     |
+----------+      +----------+      +-------------+
+ Customer + ---> + Relation + <--- + Distributor +
+----------+      +----------+      +-------------+