Help me explain Hibernate value prop to naysayers...

swordsman · **Joined:** Wed Oct 08, 2003 4:22 pm **Posts:** 29

Hello,

I am a big Hibernate fan, spreading it through our company. However some DBA-type naysayers have pushed out what they say is a roadblock to acceptance:

*they want to have a business object span multiple tables, without having to create one nested class per table.

Is this possible with Hibernate? If not, is there a good argument against it (in addition to the performance penalty of having to do a join to retrieve, and multiple inserts to store)?

TIA,

Alex

christian · **Posted:** Tue Mar 02, 2004 2:01 pm

Not possible in Hibernate 2.1.x and not sensible. Make sure you understand this implication: it is only true for "value typed properties", not for "entity association properties", which can of course, in all variants, be mapped to many tables (one-to-one with a shared primary key is probably what you are looking for).

swordsman · **Joined:** Wed Oct 08, 2003 4:22 pm **Posts:** 29

Thanks for the reply. Could you put this @ 2nd grade level please? ;-) I don't know what "value typed" vs "entity typed" is, although I suspect it has to do with mapping the embedded classes?

anthony · **Posted:** Tue Mar 02, 2004 2:05 pm

DBA???
"they want to have a business object span multiple tables, without having to create one nested class per table."???

Are DBA object experts???

It depends of what you mean by a business object span multiple tables.
If they ask you "we one 1 object for every 5 tables", it's idiot.

Now, if conceptually, the database has something to do with business and it is well done, of course you can map one object for x tables.

But i must admit the question has no sense for me.
A business model is ... a business model, not number of table / x

christian · **Posted:** Tue Mar 02, 2004 2:07 pm

Code:

class Customer {
    String name; // Mapped as "value type", pass by value semantics, column in CUSTOMER table
    Address address; // Usually mapped as "value type", some columns in CUSTOMER table
    Set orders ; // One-to-many (or many-to-many) association to "entities" (own lifecycle and identity)
     BillingInfo billingInfo; // One-to-one association to another entity, shared primary key value in two tables, CUSTOMER and BILLING_INFO
}

christian · **Posted:** Tue Mar 02, 2004 2:09 pm

Note that I don't consider the post by delpouve well informed, the DBA is your friend and usually knows much more about data modelling and business logic than the average Java developer. Talk to them.

swordsman · **Joined:** Wed Oct 08, 2003 4:22 pm **Posts:** 29

Let me explain better:

*they have an existing application and codebase
*there are 4 rule classes
*each rule populates a master table (shared across all rule types) and a child table (varies depending on the rule type)
*so the goal is for a given rule O/R mapping to span the master table and child table
*the database is 3NF, DBAs mandate that

One approach here might be to O/R map the base rule class, and then O/R map the derived classes using Hibernate's inheritance stuff? I've only worked with 1 table per class, so not familiar with this yet...

christian · **Posted:** Tue Mar 02, 2004 2:13 pm

Oh, thats easy. Use a <joined subclass> mapping and a table for every (concrete) subclass.

anthony · **Posted:** Tue Mar 02, 2004 2:14 pm

christian,
excuse, it's only my english that is poor.
When you had to developp an application with existing database, of course a big part of the knowledge is on the DBA, but in all the companies i've been working for, the DBA team had poor "object" logic, i don't want to say bad things but their job is to make relationnal model and they are experts. The development team (or conception team) has to translate the relationnal model into class diagram... that what i was trying to say
I don't know how to explain... :-(

christian · **Posted:** Tue Mar 02, 2004 2:17 pm

Just say "an object-oriented programming language usually has no data sublanguage and very poor support for a proper data model, only ad-hoc patchwork". Don't worry, its true. Aside from the libraries, framework and industry support, we don't get much from Java with regard to data management, only confusion. For example, define the term "object".

anthony · **Posted:** Tue Mar 02, 2004 2:23 pm

i'll remember it, thanks

swordsman, you'll find all about joined subclass here:
http://www.hibernate.org/hib_docs/refer ... ritance-s1

it works perfectly and easy to use

swordsman · **Joined:** Wed Oct 08, 2003 4:22 pm **Posts:** 29

Thanks for the info, looking into joined-subclass now...

gavin · **Posted:** Tue Mar 02, 2004 2:39 pm

It indeed looks like your use case is a good example of a joined-subclass mapping.

However, I am looking into providing 1-class-to-n-table mappings in 2.2 (it is actually the very next thing on my todo list).

But really, I insist that this is almost always a Bad Thing. Your object model should be at least as fine grained as the data model. Good OO design means small classes. (Sounds a bit hypocritical coming from me since there are some quite large classes in Hibernate but anyway...)

swordsman · **Joined:** Wed Oct 08, 2003 4:22 pm **Posts:** 29

Thanks, Gavin! This is v. helpful - in case there is not one abstract class / interface per table (poor OO design, but they wrote it not me) then it will be supportable in then forthcoming release. This is the ammunition I needed.