Of the mapping strategies that Hibernate presents in the 3.0 docs:



What strategy best fits when it takes multiple tables in a joined query to create a single POJO/Class? Or is there a strategy for this?

My POJOs don't involve one table during creation, they involve querying multiple tables to compile data for a POJO creation. I know the mapping file has you reference a table per class. Can I have multiple tables per class?

Thanks!

-jay

"Entity-type" and "Value-type" are two Hibernate concpets on your problem, which is described not precisely.

<<Hibernate in Action>> may be helpful.

I guess that you are looking at different thing, things like


are for polymorphic queries and inheritance.

If you want to create POJO from many tables use join:
http://www.hibernate.org/hib_docs/v3/re ... ation-join

Lukasz

Thank you very much for your response on this...

So here is my exact scenario that I am trying to determine if Hibernate/ORM is the right solution.

I have a project right now that is a J2EE application (web interface, SLSB Session Facade, DAOs, TOs, etc). The database is an Oracle system but is structured from an older set of requirements, so to retrieve data that is required for the business may take multiple tables and we currently do not have the control to modify and alter these tables. In one scenario, we pull data from about 22 tables to build a TO (POJO). This TO consists of properties and list of other TOs (one-to-many). To retrieve the lists and the properties may take multiple queries. Additionally, one of the sub TOs that is contained in the main TO, will be used to update a new table. So we have the ability to query an old database, hold onto that data, supply a user a HTML form, let them enter new data, put all that data together and pass it to iText for pdf generation, while saving off the form data into a table.

Now, I have been trying to push ORM solutions into our architecture for its cleaniness from our current JDBC implementations. Is the scenario I described above see right for ORM. Our DAO classes are littered with tons of hard-coded SQL queries and parsing resultsets...etc. Would creating a TO (POJO) from about 22 tables with Hibernate and joins be the most efficient way?

Thanks for your help!!!

jay

It depends how you are using the data. If you need to read a whole object it will be as efficient as creating 22 joins on tables on select.
If you select object and work on certain table only - hibernate offers you fetch="select" property - this allows you to load base tables and when used load the tables that are needed. This works fine if you load an object and work on it.

I am not sure how does the update work whether it updates the data that was changed. I assume so but I have not checked it - you may ask others or write a simple test.

Anyway from my experience loading the data from too many joined tables is a bottle neck, and does not sound like a good idea. Depending on how you are using this data maybe the Oracle's materialized view will be a better idea?

Lukasz

Thank you very much for you help.

I am received more information about our requirements and it seems that there are about 22 tables total.

But the current way we are implementing this is that we have a coordinating DAO that calls multiple DAOs (about 7). Each DAO runs a select query that may join one-three tables to populate one POJO. That POJO is return to the coordinating DAO. One all the multiple calls to the DAOs are complete, the coordinating DAO constructs the main POJO. So this main POJO is a composite object that contains other POJOs (results of smaller DAO queries). So its really building about 7 DAOs, each one having to query 1-3 tables to retrieve the required information to populate its POJO. So we are doing mulitple selects to attain this one composite POJO.

Does this sound more relevant for Hibernate?

Thanks for all your input!

jay