Open source (LGPL) object/relational persistence and query service "Hibernate 1.0" is now available. Hibernate lets you develop persistent objects following common Java idioms, including composition, association, inheritence, polymorphism and the Java collections framework.

To support a rapid build procedure, Hibernate rejects the use of code generation or bytecode processing. Instead runtime reflection is used and SQL generation occurs at system startup time.

Hibernate supports Oracle, DB2, MySQL, PosgreSQL, Sybase, Interbase, Microsoft SQL Server, Mckoi SQL, Progress, SAP DB and HypersonicSQL.

Homepage/Documentation:
http://hibernate.sourceforge.net.

Full feature list:
http://hibernate.sourceforge.net/features.html

Hibernate is free software (LGPL) and is developed by a team of volunteers. The 1.0 milestone was made possible by the work of many people who contributed code, bugfixes, suggestions over the past year.

Is it JDO1.0 compliant?

how does this compare with object relational/bridge concerning standard compliance (or plans in that direction)
feature completeness and stability

looks not too bad, but the following sentence doesnt sound too good to me:

"Only one O-R mapping straegy is properly supported: one table per class hierarchy"

This means: forget normalization in your database design.
But i really dont want to offent the reached goals of hibernate. I am still hoping for an open source solution which will cover my needs, which are in fact a lot of class to table combinations like one-class to multiple tables or vice versa.

Marc
(still hanging around and using a poorly self-made O/R
design which will in fact end in a maintenance nightmare)

reply to: marc

had the exact same thought. it is a great start though, and should be very usable if you are starting with the model and not the database.

Not too sure is Castor of any help.
http://castor.exolab.org/castor-one.html

Re: Only one O-R mapping straegy is properly supported: one table per class hierarchy

Supporting the normalized mapping style is high on the TODO list. There are times when it makes a lot of sense, particularly when mapping legacy data.

On the other hand, table joins are expensive and most of the time it is much preferrable (from a performance point of view) to map classes that must be retrieved polymorphically to a single table.

(Of course, if you don't need to retrieve two classes polymorphically, Hibernate doesn't force you to map them to the same table.)

Re: comparison to other persistence tools

I don't like to answer these kind of questions since

1. I am biased
2. OJB and Hibernate are both moving targets with steadily increasing functionality and maturity (this does not seem to be the case with Castor, though)

I suggest you try out a couple of different things yourself if you require an accurate picture. On the other hand, both Hibernate and OJB offer _very_ significant advantages over direct JDBC or CMP Entity Beans.

What we _do_ know is that some people who have tried other tools have chosen Hibernate (and vice-versa, I'm sure). You should choose the best tool for _your_ project and only you are in a position to judge that.

Re: JDO

The JDO specification defines

(a) a collection of interfaces for use by application code
(b) a set of internal implementation details of persistence layers

(b) includes the requirement that implementors work by sourcecode or bytecode preprocessing. Many developers find this an extremely undesirable approach and to the best of my knowledge no open source project has attempted to implement this. (Hence AKAIK there is no open source JDO implementation in the works.)

Hibernate _could_ choose to provide its services through the interfaces (a) and we plan to do this _if_and_when_ the JDO spec is widely adopted by vendors like IBM etc (certainly not before any robust JDO implementation exists). At present, this appears unlikely to happen, so we will stick with our (arguably much simpler/cleaner) interfaces. (There are plenty of disadvantages to the process of design-by-a-committee-of-vested-interests.)

Since Hibernate is open source, the usual fears of vendor lock-in do not necessarily apply.

P.S. A *quick* survey of some JDO implementations by startup vendors has convinced me that Hibernate is much more mature.

Thanks everyone for your interest :)

Gavin

Howdy,

I used Hibernate v0.98 on a recent project and found it to be a VERY good presistance implementation. The Query Language that it has is very much like SQL except it return objects instead of ResultSets.

Also i found the discussion groups an execelent source of all my queries (no pun intended!) as given himself answered all my questions.

Thanks Gavin,

Saqib

A new O/R mapping tool. Uhmmm. Still looking for for a tool that could provide me a solution for the next issue:

It should be able to generate the persistent classes dinamically, I mean for itself, rather than needing that the developer build the classes for the specific data model. In that way, I would be able to implement generic mechanisms, no matter the data model. AFAIK, neither Castor, nor OJB, nor Jakarta Torque does so. Just SIMPER is able to do it, but unfortunately for me, it works with filters, and I handle servlets 2.2 specs, and I can not upgrade to 2.3.

Does Hibernates offers such a functionality? Do you know any framework that helps with this particular issue? Has this been planned in JDO 1.0 specs?

Regards,

Adolfo.

You mean generate Java classes from database schema?

As yet, Hibernate can't do that. However, Hibernate _does_
have a tool to generate Java classes from O/R mappings
(And vice-versa, mappings from Java classes.)

I believe a couple of the toolset developers are interested
in your problem (it has come up before) so perhaps it will
be solved sometime soon. I guess all we would need for
this full round-tripping would be to generate the mapping
document from DB schema.

ie. we have:

Java -> mapping -> schema
mapping -> Java

we would need

schema -> mapping

for full round-tripping. Unfortunately, this step requires
an interactive tool since the user would have to provide
Java names for the database table names and columns.

I'll raise this on the devel list :)

Thanks,

it would probably require further analysis, but as far as I am concerned, none of the O/R mapping framework is able to work out the persistent objects corresponding with the tables of the schema for itself. All of them need human intervention, or some of them, give tools for it, but in any case, developer needs to use the framework with the datamodel in mind.

I intend to do a tool that could connect to a generic schema, no matter the tables structure and constraints, to make a generic database front end. But, I find that I can not use any of the frameworks since they start from the point that the developer knows the schema at development time.

Approaches? Maybe using hashmaps rather than java beans (i.e. that need to be compiled), it should be possible to, using metadata info to translate data model to the memory.
The key could be the column name and the value the value of the column for this key in the current row.

A much more difficult approach: using something as BCEL project from Jakarta which is able to compile classes in runtime.

Comments are welcome anyway.

Adolfo.

Hi Adolfo,

I've used one approach for this. What you want is basically a dynamic data structure with type information no?

Sidenote, I've attempted to apply some O-R mappers to a pretty large and sophisticed set of schemas. The mappers worked great with small schemas, but actually required more work when I tried to do something sophisticated. It turned out that well coded SQL run as prepared statements that generated the program data objects worked better and faster than the OR mappers. It's my opinion that in a lot of cases these mappers are a lot more trouble that they are worth. Remember you might be betting your job on the performance of an unproven design. I'm better more than one person lost his job because EJB didn't live up to it's billing and he wasn't able to get a system together in a timely fashon.

Here is what I did for the dynamic data structure problem. I created a collection object that worked a lot like a Hashmap but it stored type information too. So it stored key, type and value. Not just key/value. Also it had the ability to aggregate itself.

Whatever way you go don't buy into the hype. A simple clean maintainable design will always work better than one using the latest fad (EJB, JDO, object overkill, O-R mappers) whatever.

<quote>
Whatever way you go don't buy into the hype. A simple clean maintainable design will always work better than one using the latest fad (EJB, JDO, object overkill, O-R mappers) whatever.
</quote>
These were my concerns as well regarding the mappers. I still think they do have a point for certain use cases and certain project sizes / complexities. However, the O-R mappers are not silver bullets either. And I still prefer a solid data model on which to build the data processing applications than starting building an application and then figure out how to use the same data for other applications. OO techniques are great for building applications.

I think the mismatch is with the fundamental concept in the relational model of data independece with the concept of encapsulation in the OO world. Every successful project has followed a methodology where the data layer and the application layers were designed using the best practices for each. It's hard to get a good application on a badly designed data layer. However, where you can use the O-R tools to generate the glue for you, it's a time saver. Just need to use it carefully.

to One Ovthafew:

<quote>
Re: Only one O-R mapping straegy is properly supported: one table per class hierarchy

Supporting the normalized mapping style is high on the TODO list. There are times when it makes a lot of sense, particularly when mapping legacy data.
</quote>

Nearly all my projects are integration projects into
legacy systems and applications like IBM iSeries. In this
scenario i cant change the database design cause a lot
of "host-programmers" would kill me.

So even it would make sense to do a class->table design
(many DB designers will see this very different) i dont
have the choice.

But i appreciate that you are currently on this issue.

marc

<quote>
Re: Only one O-R mapping straegy is properly supported: one table per class hierarchy

Supporting the normalized mapping style is high on the TODO list. There are times when it makes a lot of sense, particularly when mapping legacy data.
</quote>

I would be very unhappy if I would have my projects running off a "de-normalised" relational data model. Sacrificing data integrity and the benefits of solid relational data models (based on theories, not fairytales) is short-sighted and simply just postpone the costs of maintenance for later.

I understand that in particular situations, when dealing with huge amounts of data, the programer has to interfere with the physical level of the DBMS and denormalise for certain queries. I cannot understand how people with solid data processing education can start building mid to large size projects assuming a denormalized data model.

The only positive side in all this is that integration and refactoring/rewriting costs will be kept high, keeping people in the industry busy for a while ;-)

Actually, the approach of mapping multiple classes to a single table is a _very_ standard approach. There is nothing particularly contreversial about it. The justification is that:

1. When retrieving an instance of a subclass, we never retrieve the subclass attributes without also retrieving the superclass attributes

2. When retrieving an instance of a superclass, we never know that it isn't also an instance of a subclass

Hence, we are forced to choose between

1. often requiring multiple (potentially many) queries to retrieve a single object
2. ALWAYS using an outerjoin
3. using a denormalized table design

Since the performance cost of outerjoins almost always outweighs the (minimal) cost of the extra diskspace required to store some nulls, (3) is the preferred option for most people. It certainly does not sacrifice data integrity!

Of course, optimally we would like to be able to pick and choose between (2) and (3). Hibernate will eventually let you do this. In the meantime, I am quite happy that the provided functionality is suitable for many applications.

Please note that Hibernate _does_ support one-to-one associations. So if you happen to have an existing normalized data model you can easily map it to an object model that uses association in place of inheritance.

Gavin

<quote>
Since the performance cost of outerjoins almost always outweighs the (minimal) cost of the extra diskspace required to store some nulls, (3) is the preferred option for most people. It certainly does not sacrifice data integrity!
</quote>

Sorry if I sounded too harsh in my previous message, it was not the intent :-) I am still - like all of us - in search of a nic e and clean methodology to keep the data model clean while providing enough automation and performance enhancements for the object layer. The targe is, that while doing the analysis and design of a new project/application following OO methods, I would still like to have a DBMS layer that is clean and makes full use of the benefits of a relational model.

This is why I am a bit scared always when the data layer is somehow hidden behind the mapping engine. And also experience shows that the data store will be accessed by different tools and applications in time, reports will have to be run on it, so future maintenance is not just simply upgrading the mapping engine and migrating the data in a new model provided by the mapping tool vendor.

I know you are already addressing this by looking at ways to take a schema and generate the object layer. I appreciate the work and I will follow the space closely.

<q>And also experience shows that the data store will be accessed by different tools and applications in time, reports will have to be run on it, so future maintenance is not just simply upgrading the mapping engine and migrating the data in a new model provided by the mapping tool vendor. </Q>

It doesn't have to be if one uses the right tools and techniques. Many Reporting tools now allow you to report off of XML and Java Objects. A report is no less a user interface than a standard GUI. To make OO really work nothing but the application designed to access the datastore should access it. The application may provide data to a 'data warehouse' for reporting purposes.

A feature that I never seen implemented in any O/R persistence tool is the ability to load in one request informations from a 1-n relationship. By example, when I read on object Product, I would like to read directly, in the same request, his name’s translation from another table whose primary key is prod_id and language_id. If a request return 100 objects, I don’t want to do 100 requests just to have their translation just after.

Is their any O/R framework able to do that ?

Adrien

re: bulk loading of 1:N relationships

TopLink can do that.

Please see http://otn.oracle.com/products/ias/toplink/content.html

<quote>
To make OO really work nothing but the application designed to access the datastore should access it. The application may provide data to a 'data warehouse' for reporting purposes.
</quote>

Reporting is just one case. All the applications written today know how to talk with databases (either via JDBC or ODBC). Try to get off-the-shelf applications that will work with your won object model. You also mention XML. Maybe, probably, when the web-services will really take off. Until then, you really don't want to manage your relational data via XML.

Again, it's the same disconnect between the data independence concept fundamental to relational databases and the encapsulation of the OO models.

There's a lot of fear and invective being thrown up in the face of O-R tools. No, they're not perfect. But what is? Your alterative is to write your own persistence mechanism. Regardless of the complexity of your data model, there's a lot that your home-grown persistence mechanism will have to account for when you start dealing with object relationships. For a system of any real complexity (say, 10 or more objects with about 10 attributes each), that's a hell of a lot of code to handwrite. If you don't want to handwrite all of that, you have to do code generation. Rejecting an O-R mechanism doesn't save you any hassle; it means you're dealing with the hassle instead of someone else. Having dealt with that hassle in numerous ways on numerous projects, I've been looking for a good solution for a long time and the latest OR tools seem (to me, anyway) to be good enough for 80% of the projects out there.

If you're starting a new project from scratch, what's the big deal about using an OR tool? What possible complexity could you be introducing for most of the applications out there that an OR mapper couldn't handle PROVIDED that you're starting from scratch and don't have to map to a legacy schema? For most transactional or information-sharing systems, the mapping between the objects and the tables has been done many times over, and that's the experience that has been drawn upon to create the latest generation of OR tools.

I particularly like Hibernate's reflection based approach. The author recognizes that it's a different approach than a code-gen approach and states clearly his reasons for choosing it. Makes sense to me, especially since reflection seems to work plenty fast in the latest JDKs.

As a side note, I don't think that an OR tool, or any OR framework, is a complete solution for most projects. I think that using an OR tool is great because it takes care of your major hassles regarding persistence. I find that using a separate component that does direct SQL calls is more efficient for displaying data onscreen (especially in a web environment). For example, a list of orders and their item counts could be done using SQL. It would be shown in a page by accessing a list manager behind the scenes that understands the base SQL necessary to execute, has a certain set of expected parameters configured, and is fed parameter values at runtime (e.g., user name to get a list of the user's orders). Clicking on an item in the list would bring you to a page that shows order detail, which could be fed by an object loaded using your OR framework or another list. All actions on the data (save, add, load, delete, etc.) occur through the OR framework. Note this doesn't require the use of an OR mapping tool, only a framework, which could be handcoded, code-generated, or (in my opinion, the best solution), handled through something like Hibernate. That seems to me to provide the best of both worlds, because most of the time if you're doing a complicated SQL call, it's only dictated by what you need to display onscreen.

When I stated that I enjoyed using that OR mapping tool I should have stated why.

I have done to many projects were I hand wrote the persistence code. It's time consuming as hell.

I have also done pure object projects using the Poet object database, which relies on the developer to have a good understanding of the transaction. No OR mismatch here but most projects use relational dbs.

There is just NO excuse for me to have to hand write the persistence classes for the full CRUDS + additional finders and as well as my other business objects (beans). That is extremely time consuming and mundane even if you use tools to create getters/settters from attributes. You are still stuck writing and debugging sql.

The particular tool that I mentioned does easily allow you to extend the query for finders and such.

But as was mentioned it's no silver bullet and Hibernate is also a cool tool (no byte code enhancement!!!!)

Cheers,

Cory Adams

I'm with you Cory. Most of my SQL is crud. I'm willing to do a few 'custom queries'. I tried hand coding objects and SQL in VB and about went nuts. When I moved to Java I was determined not to do it again. We used a tool that came with VAJ but will still mapped it to our own objects. And boy did it generate alot of code - much like EJBs - plus all the code it uses. With Hibernate very little and very easy to understand.

Ok...

O/R mapping tools, Java

http://jinx.swiki.net/284

Again, I don't see what kind of crazy data structures you see an OR tool creating that a reporting tool couldn't handle. For example, creating a simple object tree like this:

Client
  -name
  -startDate
  -projects (list)
Project
  -name
  -description
  -expectedFinishDate
  -client

generate two tables using Hibernate: client and project. Each attribute mapped to a field. Plus id fields and a foreign key reference in project. That's probably how you would do it without hibernate unless there's something I'm missing. A reporting tool would have to go through the same hoops to query that data in either case.

I guess as I write this, now I see your concern: if Hibernate hides all knowledge of tables from you, manages their lifecycle, and creates all kinds of weird fields for you, it's a pain to deal with. But at least for this OR tool, it seems to me that it lets you control the table structure and map fields to attributes pretty well.

If you have more exotic reporting needs, they're probably going to require warehousing whether you use an OR tool or not, because the basic kind of object to table mapping I described is well-suited for transactional and information-sharing systems but might not be optimal for reporting using cubes and other exotic report types. Doing warehousing then is caused by the mismatch between the requirements of the application and the requirements of reporting, not by OO vs relational conflicts.

<quote>
I guess as I write this, now I see your concern: if Hibernate hides all knowledge of tables from you, manages their lifecycle, and creates all kinds of weird fields for you, it's a pain to deal with. But at least for this OR tool, it seems to me that it lets you control the table structure and map fields to attributes pretty well.
</quote>

That's exactly my concern. If the tools generates "proprietary" database schemas to store its objects, completely hiding it from the application developer is worrying me.

I am for using O-R mapping tools but with control over the underlying schema. Of course these tools save a lot of time, especially in cases where the usage patters are common and proven over and over again.
I remember that it was quite natural for example to use the "relational views" idea implemented in early ATG application servers. You had the full power of SQL without having to do a lot of repetitive code writing.

<>I am for using O-R mapping tools but with control over the underlying schema<>

You have that with Hibernate.

Ok, HTML (JSP's, Tapestry, Struts, etc), WebServices.

>All the applications written today know how to talk with
>databases (either via JDBC or ODBC). Try to get off-the-
>shelf applications that will work with your won object
>model.

They know how to talk to their database models. What applications are you talking about? I would say that these applications are not well written if they can only communicate to databases. Get/write better applications.

>You also mention XML. Maybe, probably, when the web-
>services will really take off. Until then, you really
>don't want to manage your relational data via XML.

XML is not Web services and has MANY uses besides that. Web Services can be accomplished without XML.

I wasn't saying to manage databases with XML. I was saying XML can be provided to applications/tools if that is what they can use and/or they can't use Java Objects. Check out any current reporting tool.

<quote>
They know how to talk to their database models. What applications are you talking about? I would say that these applications are not well written if they can only communicate to databases. Get/write better applications.
</quote>

I don't really like to continue this argument. What I said was that I see the usefulness of O-R tools for saving time and repetitive coding, and sometimes enhancing performance with instance caching. The only requirement I have is to have control on the schema.

If you want, I am a believer in the relational model and the solid theories behind it, including the fundamental concept of data independence. That theory allows for the development of data management systems, where the focus is on "data". Basically those systems are better suited for "data management" than the OO systems, which are great building applications giving meaning to that data. I would not sacrifice the data independence for the sake of the application layer, that's all.
This does not exclude using O-R tools and I appreciate the work put in by the community in that area and I did use nice O-R mapping tools.

<Q>What I said was that I see the usefulness of O-R tools for saving time and repetitive coding, </Q>

So why repeat the code in Web Services and Html pages and App to App communication and batch programs?


<Q>The only requirement I have is to have control on the schema</Q>

And you can with Hibernate.

I'm not trying to agrue with you. From your comments it seems you just don't understand.

At issue is that the data can seldom exist on its own. There is almost some additional logic/info that cannot be represented in the data and the data layer. Don't suggest triggers and stored procs. They usually contain embedded business logic and is what you don't want. Much of the 'data' today doesn't even exist in relational databases. So couple these things with the issue that any change in the data structure (ie: a minor name change) will have to reflected in every tool/application that accesses the "database" and you have a maintenance nightmare. It is much easier to find out what libraries use a certain object or library than it is to find out what applications use a certain field from database. I've tried and it is horrible.

Mark

<quote>I'm not trying to agrue with you. From your comments it seems you just don't understand. </quote>

What I understand (but do not agree) is that you are arguing for a pure-OO approach, where all the applications accessing the data should do it via an object layer that would ideally be provided by an O-R mapping tool. Any special "slicing-and-dicing" should be done through the datawarehouse.

If you really have control over all the variables of this environment, it could actually work. It kind of excludes legacy integration but I am not going there.

I agree with you regarding changing (and chasing) data layer changes that propagate all the way through the other layers. I just think that the puristic approach migh not be totally realistic. I would love to hear that it works like that. Full lifecycle in an OO world, over several generations of tools and business needs, never even thinking about the underlying schema. Hmmm...

<>It kind of excludes legacy integration but I am not going there.<>

We are doing that and no it doesn't



<>I just think that the puristic approach migh not be totally realistic<>

Well I agree with this, but than doesn't preclude one from hiding the details from the rest of the 'world'.

<>never even thinking about the underlying schema.<>

I do think about it. Those who access our application and 'data' don't.

Ok, it seems that we agree :-) To be honest, I did not totally understand which way each tool goes. In some reviews I read about JDO implementations, some of them actually do manage table lifecycle, introduce weird attributes and all that.

I got it now that hibernate does not do that, and that's good. Some time ago I used ATG's "relational views", which were close to some of other mappers. That worked well on mid-to-big scale projects, so I believe that other tools do a good job as well. I am just very careful with my "data", that's the most important asset for the company (on the IT side, of course) :-)

:)

To further that, if a RDBMS is used as the persistance store then things like triggers, etc will have to be used. Again, this should be hidden from those using the system.

As for important assets. The data is very important asset. But I would say it is no less important than the 'code' that creates it and manipulates it. And also no less than the business rules if whether they are in the code or some tool.

Gavin,

What happens if you have a very large number of classes mapped to a single table? The outerjoins will probably be a lot faster alternative. Not to mention that a table with 100 million rows is quite a nighmare for a DBA.

Yes, Hibernate runs under JDK1.2 (it detects the JVM version and disables use of dynamic proxies). Hibernate may even be compiled under JDK1.2.

>> What happens if you have a very large number of classes mapped to a single table? The outerjoins will probably be a lot faster alternative. Not to mention that a table with 100 million rows is quite a nighmare for a DBA.

Of course. But then it is _extremely_ unlikely that you will need to access that many classes polymorphically.

ie. Nobody tries to write queries like:

  select o from o in class java.lang.Object

its usually more like

  select cust from cust in class Customer

where the Customer class has a small number of subclasses. Just because Customer and Employee both inherit Person doesn't mean they need to reside in the same table unless you have queries that return both Customers and Employees polymorphically (ie. in the same result set).

Will Hiberbate work with JDK 1.2? We're using VAJ 4 which only uses JDK 1.2.2.

Similar open source projects:

http://sql2java.sourceforge.net/

ObjectBridge
http://jakarta.apache.org/ojb/

http://jrf.sourceforge.net/

http://objectbridge.sourceforge.net/

http://jgrinder.sourceforge.net/

http://hibernate.sourceforge.net/

Castor JDO
http://www.castor.org/

JORM
http://www.objectweb.org/jorm/index.html

JBoss JAWS project (JBossCMP)
http://www.jboss.org/developers/projects/jboss/jaws.jsp

http://objectstyle.org/cayenne/

Jakarta Torque
http://jakarta.apache.org/turbine/torque/



See also:

JDO
http://www.jdocentral.com/

http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html

http://www.ambysoft.com/mappingObjects.html

Java DAO (Data Access Objects)
http://sourceforge.net/projects/basejdao

One more:

http://databind.sf.net/

Would be useful if someone can also post personal experiences or compare between the major ones listed above.

Somebody asked about generating classes from a db schema.... Of course there are the mighty CocoBase and TopLink products but I have had great success with JDatabase Wizard.

JDatabase Wizard can generate JDBC classes and or ejb cmps. It also generates the deployment descriptors for you. If your schema changes rerun the wizard for that table.

I have used it in a continous development process with ant + unit testing and it worked out very well.

Check: http://www.j3ltd.com/wizard/overview.htm

It is not open source and is priced at $199 US.

I wish Hibernate could generate it's map by introspecting a db as this tool and other commercial O/R mapping tools do...... But if wishes were horses beggers would ride and we would all be paid $300/hour =)

Best regards,

Cory

Oh god another worthless O-R Mapper.

I hate these things.

The object model isn't as flexable as the relational model therefor none of these object based systems will ever give you the functionality that you need in the real world. The relational model is based on static relationships that can be viewed in a dynamic way. With the exception of polymorphism the object model is based on static relationships that can be viewed in a static way.

You will always have to rely on hacks like views on top of complicated schemas because OR mappers and OQL languages won't be as sophisticated as the underlying database.

If you go to the trouble of building an abstraction on the schema (a database view) you could have just written the query in the first place. As it would be faster (prep statement), cleaner, easier to maintain and only have your bugs in it not your bugs + the persistance engine bugs.

Just say no to OR mappers. You will save yourself pain in the long run.

The main thing I missed was the ability to do aggregates. I beggined recently a project that would need a lot of sums, counts and avgs. I did not use Hibernate, because it does not have it.
However, I have a question. It's possible to map a class to a table with hibernate. However, is it possible to map a query result to a class, as Oracle's BC4j do, for example?

> do manage table lifecycle, introduce weird attributes and > all that.

Hibernate is foremost a MAPPING tool. It lets you map existing classes to existing tables by specifying mapping metadata in an XML format.

Now, if you _like_, you may use a tool to (partially) generate a default mapping document. You may then edit this document to adapt to legacy database tables. This tool is not an essential part of the process, however. It is merely a shortcut.

Theres another tool to generate + export schemas (including referential integrity constraints and indexes) given the mapping document. But again, you don't *have* to use this.

>The main thing I missed was the ability to do aggregates.
>I beggined recently a project that would need a lot of
>sums, counts and avgs. I did not use Hibernate, because it
>does not have it.

The reason Hibernate doesn't have these things in its query language is because SQL already has them! Hibernate queries are designed to return objects, not aggregate values. Hibernate always exposes the JDBC connection its using so you can just execute an SQL query if you wish to do something that SQL is already well suited to.

Hibernate isn't trying to take anything away from you that JDBC provides. It just adds some extra object-oriented functionality _if_and_when_ thats what you need. I must stress the fact that Hibernate is most definately NOT a framework. It doesn't try and restrict the way you design and implement the application. Think of it like JDBC that returns JavaBeans :)

> It's possible to map a class to a table with hibernate.
> However, is it possible to map a query result to a class,
> as Oracle's BC4j do, for example?

If you mean is it possible to force Hibernate to instantiate instances of persistent objects from the results of an SQL query, no, its not. You *could* select the primary keys and then have Hibernate load the objects one-by-one. This would not be a very high-performance solution, though.

peace

Gavin

Gavin,

You said:

"The reason Hibernate doesn't have these things in its query language is because SQL already has them! Hibernate queries are designed to return objects, not aggregate values. Hibernate always exposes the JDBC connection its using so you can just execute an SQL query if you wish to do something that SQL is already well suited to. "

and

"
If you mean is it possible to force Hibernate to instantiate instances of persistent objects from the results of an SQL query, no, its not. You *could* select the primary keys and then have Hibernate load the objects one-by-one. "

Ok, how can I use the SQL features that hibernate doesn´t provide, like aggregates? Must I implement it myself?

> provide, like aggregates? Must I implement it myself?

It's possible I have misunderstood your requirements. I can
see two ways you might want to use aggregates:

1. To retrieve some aggregate data: eg.

  select avg(price) from product
  select avg(price) from product group by supplier

2. In a subselect when retrieving objects

  from p in class Product where p > select avg(price) from product

Hibernate doesn't give you the necessary flexibility to do things like (2). However, these kind of cases you could easily rewrite it as an SQL query or queries, followed by a Hibernate query.

As for the kind of thing in (1), you aren't trying to retrieve objects so you can use SQL. Just do something like:

 Session s = factory.openSession();
 .....
 ResultSet rs = s.connection().prepareStatement("select avg(price) from product").executeQuery();
 .....

Okay, it would be *nicer* if you could use all the extra OO features of Hibernate queries and write something like:

  select max(p.price) from p in class Product where p.supplier.name = ?

but this is hardly a reason to reject Hibernate and choose JDBC! It *might* be a reason to reject Hibernate and choose some commercial tool that costs hundreds or thousands of dollars per seat.

One of these days Hibernate will support this kind of thing, actually. Its not currently at the top of the todo list unless someone wants to volunteer to implement it!

>I beggined recently a project that would need a lot of
>sums, counts and avgs. I did not use Hibernate, because it
>does not have it.

It does now :)

Just finished implementing support for queries like:

  select foo.type, max(foo.count), count(distinct foo) from foo in class eg.Foo where foo.bar.size > 2 group by foo.type

this functionality is in CVS and will be in the next release 1.0.1 due out this week.

thanks for inspiring me to do this....

Gavin

"this functionality is in CVS and will be in the next release 1.0.1 due out this week. "
I'll be the first to use it.


"thanks for inspiring me to do this.... "
You're welcome.