Hibernate 2.0, the open source persistence framework, has been released.
Hibernate2 features substantial redesign in:
- id generator framework
- configuration APIs
- interceptor
- callbacks
- collections
- package organization
- naming exception model
- new mapping format
- new "cool" features
Hibernate2 is not a drop-in replacement for Hibernate 1.2. Code changes will certainly be required. However, we expect that these changes will be of the trivial, automatable variety and that no application redesign will be necessary (unless you are using toplevel collections).
See More
--------
Hibernate Home Page
Hibernate Feature List
Download Hibernate 2.0
-
Hibernate 2.0 Released (132 messages)
- Posted by: Peter Monks
- Posted on: June 09 2003 01:54 EDT
Threaded Messages (132)
- Hibernate 2.0 Released by Paul Danckaert on June 09 2003 10:02 EDT
- Hibernate 2.0 Released by Sandeep Dath on June 09 2003 10:07 EDT
- Hibernate MIddlegen plugin by David Channon on June 09 2003 19:57 EDT
- Is Hibernate related to JDO? by Frank Cohen on June 09 2003 10:10 EDT
- Is Hibernate related to JDO? by Christophe Vanfleteren on June 09 2003 10:16 EDT
-
JDO? by Frank Cohen on June 09 2003 11:07 EDT
-
JDO? by Ryan Breidenbach on June 09 2003 11:43 EDT
- Thanks by Frank Cohen on June 09 2003 01:34 EDT
-
JDO? by Juergen Hoeller on June 09 2003 01:54 EDT
-
Hibernate / JDO / CMP by Corby Page on June 09 2003 02:11 EDT
-
Hibernate / JDO / CMP by Tero Vaananen on June 09 2003 03:06 EDT
- Hibernate / JDO / CMP by Corby Page on June 09 2003 03:50 EDT
-
Hibernate / JDO / CMP by Erik Bengtson on June 09 2003 03:55 EDT
-
Hibernate / JDO / CMP by Corby Page on June 09 2003 04:52 EDT
- Dynamic Data Routing with JDX O/R Mapper by Damodar Periwal on June 09 2003 09:33 EDT
-
Hibernate / JDO / CMP by Steve Cramer on June 09 2003 09:54 EDT
- Multiple table mapping by Sam Terrell on June 10 2003 12:03 EDT
- Dynamic tables by Gavin King on June 09 2003 10:14 EDT
-
Dynamic table targets by Jonathan Ginter on June 11 2003 11:46 EDT
- Dynamic table targets by Juozas Baliuka on June 11 2003 01:06 EDT
-
Use database table partitionning instead by Nicolas DASRIAUX on July 24 2003 04:44 EDT
- How Database Partionning Entry Relates To Hibernate by Nicolas DASRIAUX on July 24 2003 04:50 EDT
-
Hibernate / JDO / CMP by Corby Page on June 09 2003 04:52 EDT
- DBRouting in Persistence EdgeXtend by Michael Alderete on June 09 2003 05:19 EDT
-
Hibernate / JDO / CMP by Tero Vaananen on June 09 2003 03:06 EDT
- JDO? by Juergen Hoeller on June 09 2003 03:12 EDT
-
JDO? by Erik Bengtson on June 09 2003 03:44 EDT
-
JDO? by Juergen Hoeller on June 09 2003 04:09 EDT
- JDO? by Erik Bengtson on June 09 2003 04:27 EDT
- JDO? by Thomas Risberg on June 09 2003 05:32 EDT
-
xPetStore by Eric Samson on June 10 2003 09:11 EDT
-
xPetStore by Juergen Hoeller on June 10 2003 10:11 EDT
- xPetStore by Eric Samson on June 10 2003 10:25 EDT
-
xPetStore by Juergen Hoeller on June 10 2003 10:11 EDT
-
Don't believe this! by Gavin King on June 09 2003 08:38 EDT
-
Don't believe this! by Erik Bengtson on June 10 2003 03:52 EDT
- umm by Gavin King on June 10 2003 04:18 EDT
-
Don't believe this! by Erik Bengtson on June 10 2003 03:52 EDT
-
JDO? by Juergen Hoeller on June 09 2003 04:09 EDT
-
JDO vs. Hibernate by Michael Mattox on June 10 2003 12:47 EDT
-
JDO vs. Hibernate by Juergen Hoeller on June 10 2003 06:24 EDT
-
yes, but by Gavin King on June 10 2003 06:56 EDT
-
JDO Optimistic Transactions by Gavin King on June 10 2003 07:16 EDT
- JDO Optimistic Transactions by David Tinker on June 10 2003 07:41 EDT
-
JDO Optimistic Transactions by Gavin King on June 10 2003 07:16 EDT
- JDO Optimistic Transactions by David Tinker on June 10 2003 06:59 EDT
-
yes, but by Gavin King on June 10 2003 06:56 EDT
- Hibernate with ODBMS by yves yang on July 10 2003 07:35 EDT
-
JDO vs. Hibernate by Juergen Hoeller on June 10 2003 06:24 EDT
- JDO? by Oz Kologlu on June 10 2003 12:56 EDT
-
Fatal flaw or remediable blemish? by David Ezzio on June 10 2003 01:43 EDT
-
correction by Gavin King on June 10 2003 01:54 EDT
-
Hibernate Transparent? by David Tinker on June 10 2003 07:18 EDT
-
CGLIB by Gavin King on June 10 2003 07:28 EDT
-
CGLIB by David Tinker on June 10 2003 07:56 EDT
- CGLIB by Gavin King on June 10 2003 08:34 EDT
-
CGLIB by David Tinker on June 10 2003 07:56 EDT
-
CGLIB by Gavin King on June 10 2003 07:28 EDT
-
correction by Eric Samson on June 10 2003 09:20 EDT
-
correction by Juozas Baliuka on June 10 2003 05:45 EDT
- correction by Cedric Beust on June 10 2003 06:18 EDT
-
correction by Juozas Baliuka on June 10 2003 05:45 EDT
-
Hibernate Transparent? by David Tinker on June 10 2003 07:18 EDT
-
Fatal flaw or remediable blemish? by Juergen Hoeller on June 10 2003 06:36 EDT
-
JDO Identity by David Tinker on June 10 2003 07:11 EDT
-
Aha by Gavin King on June 10 2003 07:23 EDT
-
Aha by David Tinker on June 10 2003 08:07 EDT
- Aha by Juergen Hoeller on June 10 2003 08:35 EDT
-
Aha by David Tinker on June 10 2003 08:07 EDT
-
JDO Identity by Robin Roos on June 10 2003 07:53 EDT
-
JDO Identity by Thomas Risberg on June 10 2003 11:06 EDT
- JDO Identity by Eric Samson on June 10 2003 11:26 EDT
- JDO Identity by Eric Samson on June 10 2003 11:28 EDT
-
JDO Identity by Thomas Risberg on June 10 2003 11:06 EDT
-
Aha by Gavin King on June 10 2003 07:23 EDT
-
JDO Identity by David Tinker on June 10 2003 07:11 EDT
-
correction by Gavin King on June 10 2003 01:54 EDT
-
Why not use Hibernate in the first place then? by Eric Samson on June 10 2003 08:45 EDT
-
getting squeezed out of the market. by Gavin King on June 10 2003 09:14 EDT
- out of the market ? by Eric Samson on June 10 2003 09:40 EDT
- Hibernate JDO benchmark by Eric Samson on June 10 2003 09:46 EDT
- out of the market by Eric Samson on June 10 2003 09:48 EDT
-
support from big names by Eric Samson on June 10 2003 09:50 EDT
- support from big names by Erik Bengtson on June 10 2003 10:05 EDT
-
support from big names by Juozas Baliuka on June 10 2003 10:36 EDT
-
Hibernate a standard by Eric Samson on June 10 2003 10:50 EDT
-
Hibernate a standard by Ryan Breidenbach on June 10 2003 11:45 EDT
- Hibernate a standard by Erik Bengtson on June 10 2003 12:05 EDT
-
Hibernate a standard by Ryan Breidenbach on June 10 2003 11:45 EDT
-
Hibernate a standard by Eric Samson on June 10 2003 10:50 EDT
-
data source support by Eric Samson on June 10 2003 09:55 EDT
-
data source support by Juozas Baliuka on June 10 2003 10:19 EDT
- data source support by Juergen Hoeller on June 10 2003 10:56 EDT
-
data source support by Juozas Baliuka on June 10 2003 10:19 EDT
-
Let's roll the dice by David Ezzio on June 10 2003 10:06 EDT
- suitably chastened by Gavin King on June 10 2003 10:35 EDT
-
Oh no, not another benchmark by Cedric Beust on June 10 2003 10:45 EDT
- Oh no, not another benchmark by Ryan Breidenbach on June 10 2003 10:50 EDT
-
benchmarks by Eric Samson on June 10 2003 10:58 EDT
-
Hibernate or LiDO by Christian Sell on June 10 2003 12:25 EDT
-
LiDO Hibernate by Eric Samson on June 10 2003 02:46 EDT
-
LiDO Hibernate by Ryan Breidenbach on June 10 2003 03:02 EDT
-
LiDO Hibernate by Eric Samson on June 10 2003 04:42 EDT
-
LiDO Hibernate by Ryan Breidenbach on June 10 2003 05:39 EDT
-
FUD or not by Eric Samson on June 11 2003 01:58 EDT
-
FUD or not by Juergen Hoeller on June 11 2003 03:01 EDT
-
TV-shop by Wille Faler on June 11 2003 03:27 EDT
-
Finished by Gavin King on June 11 2003 03:53 EDT
- Finished by Erik Bengtson on June 11 2003 05:21 EDT
- Finished by Wille Faler on June 11 2003 06:24 EDT
-
Finished by Eric Samson on June 11 2003 06:46 EDT
- Finished by Erik Bengtson on June 11 2003 07:08 EDT
- Finished by Juozas Baliuka on June 11 2003 08:21 EDT
-
TV-Shop by Eric Samson on June 11 2003 06:59 EDT
- TV-Shop by Wille Faler on June 11 2003 08:29 EDT
- thread conventions by Christian Sell on June 11 2003 10:21 EDT
-
Finished by Gavin King on June 11 2003 03:53 EDT
-
TV-shop by Wille Faler on June 11 2003 03:27 EDT
- No Respect by alex chudnovsky on June 11 2003 03:25 EDT
- FUD or not by Juozas Baliuka on June 11 2003 04:59 EDT
-
FUD or not by Juergen Hoeller on June 11 2003 03:01 EDT
-
FUD or not by Eric Samson on June 11 2003 01:58 EDT
- a french company by Christian Sell on June 10 2003 06:02 EDT
-
LiDO Hibernate by Ryan Breidenbach on June 10 2003 05:39 EDT
- LiDO Hibernate by Chris Mathews on June 10 2003 05:20 EDT
-
LiDO Hibernate by Eric Samson on June 10 2003 04:42 EDT
-
LiDO Hibernate by Ryan Breidenbach on June 10 2003 03:02 EDT
-
LiDO Hibernate by Eric Samson on June 10 2003 02:46 EDT
-
Hibernate or LiDO by Christian Sell on June 10 2003 12:25 EDT
-
out of the market by Eric Samson on June 10 2003 10:12 EDT
- out of the market by Juergen Hoeller on June 10 2003 10:38 EDT
- Blah blah blah by Ryan Breidenbach on June 10 2003 10:46 EDT
- Did you really say that? by Dave Hewitt on June 10 2003 11:14 EDT
-
Hibernate is used by a Fortune 100 company that made over a bill by t g on June 10 2003 11:27 EDT
- Hibernate users by Eric Samson on June 10 2003 11:41 EDT
- Hibernate user verses LIBeLIS customer by Jeff Boring on July 10 2003 02:59 EDT
- getting squeezed out of the market. by David Ezzio on June 10 2003 10:21 EDT
- Why not use Hibernate in the first place then? by Michael Mattox on June 11 2003 03:09 EDT
-
getting squeezed out of the market. by Gavin King on June 10 2003 09:14 EDT
-
byte-code enhancement expense by Eric Samson on June 10 2003 08:46 EDT
- byte-code enhancement expense by Juergen Hoeller on June 10 2003 09:34 EDT
-
Hibernate / JDO / CMP by Corby Page on June 09 2003 02:11 EDT
-
JDO? by Ryan Breidenbach on June 09 2003 11:43 EDT
-
JDO? by Frank Cohen on June 09 2003 11:07 EDT
- Is Hibernate related to JDO? by Christophe Vanfleteren on June 09 2003 10:16 EDT
- Hibernate 2.0 Released by Herve Tchepannou on June 09 2003 15:57 EDT
- JDO instance in Two Tables by Robin Roos on June 09 2003 16:19 EDT
- Hibernate 2.0 Released by Haytham A on June 09 2003 17:53 EDT
- Hibernate vs JDO vs CMP? by Wille Faler on June 09 2003 18:04 EDT
- Docs are good, an easy to read, organized book even better by t g on June 09 2003 19:27 EDT
- Docs are good, an easy to read, organized book even better by David Channon on June 09 2003 20:03 EDT
- Congratulation! by Renat Zubairov on June 10 2003 01:01 EDT
- The official announcement by Gavin King on June 10 2003 05:34 EDT
- The official announcement by Erik Bengtson on June 10 2003 05:55 EDT
- OJB? by Uladzimir Liapko on June 10 2003 07:49 EDT
- Hibernate 2.0 Released by Ray Harrison on June 10 2003 09:13 EDT
- EMF/CWM by Stefan Tilkov on June 11 2003 16:06 EDT
- Hibernate 2.0 Released by Erik Bengtson on June 11 2003 03:40 EDT
- Let's not forget a big "THANK YOU" to Gavin King by Henrik Klagges on June 12 2003 16:08 EDT
- I have been reading this thread and... by Web Master on June 21 2003 23:14 EDT
-
I have been reading this thread and... by shi yiying on June 24 2003 04:27 EDT
-
I have been reading this thread and... by Juozas Baliuka on June 25 2003 04:19 EDT
-
Object is the Root and Relational is the Leaf by Lu Yunhai on June 26 2003 12:49 EDT
- Object is the Root and Relational is the Leaf by Juozas Baliuka on June 26 2003 06:51 EDT
- I have been reading this thread and... by shi yiying on June 26 2003 02:41 EDT
-
Object is the Root and Relational is the Leaf by Lu Yunhai on June 26 2003 12:49 EDT
- I have been reading this thread and... by Jerome Beau on July 08 2003 07:40 EDT
-
I have been reading this thread and... by Juozas Baliuka on June 25 2003 04:19 EDT
-
I have been reading this thread and... by shi yiying on June 24 2003 04:27 EDT
- I have been reading this thread and... by Web Master on June 21 2003 23:14 EDT
-
Hibernate 2.0 Released[ Go to top ]
- Posted by: Paul Danckaert
- Posted on: June 09 2003 10:02 EDT
- in response to Peter Monks
This is great! I've been using the 2.0 RC Candidates for a while on a new project and haven't found any real problems with it. Any time I sit down to debug a hibernate problem, I've always found it to be a mistake of mine in a mapping file somewhere..
Using Hibernate with a DAO design makes it really easy to migrate your application around as well. You can deploy in that servlet engine.. an app server.. or wherever you need to.
I'm just waiting for the Hibernate 2 xdoclet support to be finalized.. (atleast it wasn't last I checked), since that helps skip the mapping file work. -
Hibernate 2.0 Released[ Go to top ]
- Posted by: Sandeep Dath
- Posted on: June 09 2003 10:07 EDT
- in response to Peter Monks
What about the Middlegen and AndroMDA plugins? Is that supported and fully functional as well?
Also, when will there be an actual release for the Middlegen plugin?
Sandeep. -
Hibernate MIddlegen plugin[ Go to top ]
- Posted by: David Channon
- Posted on: June 09 2003 19:57 EDT
- in response to Sandeep Dath
We have release a preview of the Hibernate Middlegen plugin for Hibernate 2 on the Hibernate download page. It is a significant plugin that will generate the mapping documents. The plan is to release the plugin officialy with Middlegen 3b1.
David -
Is Hibernate related to JDO?[ Go to top ]
- Posted by: Frank Cohen
- Posted on: June 09 2003 10:10 EDT
- in response to Peter Monks
Looks really cool - and it's free software under the LGPL.
I'm wondering how Hibernate relates to JDO? The Hibernate Web site says Hibernate provides transparent persistence, including "No required interfaces or base classes for persistent classes, no strange collection classes exposed to application code, support for Java array." I wish their Web site dug into this in more depth - at least I didn't find it. Especially the "no strange collection classes" comment. That's interesting!
-Frank Cohen
http://www.pushtotest.com
TestMaker 4 now in beta. -
Is Hibernate related to JDO?[ Go to top ]
- Posted by: Christophe Vanfleteren
- Posted on: June 09 2003 10:16 EDT
- in response to Frank Cohen
Looks really cool - and it's free software under the LGPL.
>
> I'm wondering how Hibernate relates to JDO? The Hibernate Web site says >Hibernate provides transparent persistence, including "No required interfaces or >base classes for persistent classes, no strange collection classes exposed to >application code, support for Java array." I wish their Web site dug into this in >more depth - at least I didn't find it. Especially the "no strange collection >classes" comment. That's interesting!
What they mean is that you can use regular collection classes (well, at least their interface, eg, Set, Collection, Map, ...) in your code.
For example, when you do a query, you can retrieve the results as a Collection.
They use their own collection classes in the background, wich allows them to implements things like lazy loading transparently for the developper. -
JDO?[ Go to top ]
- Posted by: Frank Cohen
- Posted on: June 09 2003 11:07 EDT
- in response to Christophe Vanfleteren
Thanks for the response. How is Hibernate different from JDO?
-Frank
http://www.PushToTest.com
TestMaker 4 is in beta -
JDO?[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: June 09 2003 11:43 EDT
- in response to Frank Cohen
JDO is an API for persisting Java objects. It provides a layer of abstraction so that applications that use JDO are not dependant on a particular persistence mechanism - they simply code that JDO APIs. Vendor-specific solutions provide the implementation of the interface. There are implementation of the JDO spec that support relational databases and object databases.
Think of it this way:
- You code you web apps to the Servlet API. WebSphere, Tomcat, Resin, etc provide the implementation of the servlet engine.
- You code your persistence to the JDO API. Various vendors provide the implementation.
Hibernate is a object/relational mapping tool. It allows you to specify how your object model should be persisted to a relational database in a mapping file. Once this is done, Hibernate does the "dirty work".
Ryan -
Thanks[ Go to top ]
- Posted by: Frank Cohen
- Posted on: June 09 2003 13:34 EDT
- in response to Ryan Breidenbach
That helped alot. -Frank -
JDO?[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 09 2003 13:54 EDT
- in response to Ryan Breidenbach
Of course there are object/relational mapping implementations for JDO. So Hibernate does directly compete with those JDO products, like SolarMetric's Kodo and Libelis' Lido. Note that there isn't any open source JDO implementation that provides a similar feature set yet. It also competes with classic O/R mappers like TopLink and CocoBase, using a quite similar approach.
The main differences between Hibernate's approach and JDO's is the state management. Hibernate uses plain unmodified Java objects, checking for changes via reflection and specialized implementations of the standard Java collection interfaces. JDO requires bytecode-modified objects that implement its PersistenceCapable interface after the postprocessing, delegating every property access to the JDO StateManager. Thus, JDO's dirty detection is more efficient, but comes at the expense of the need for modified objects.
Unfortunately, JDO's object modification approach does involve severe drawbacks. For example, persistent objects cannot be read or written outside of an active JDO transaction (by default), as they get their values from the JDO StateManager instead of their instance variables. And even when leveraging all options, persistent objects cannot be reassociated with a new transaction of a new PersistenceManager instance.
The latter is a typical use case for web apps: Load an object in one transaction/connection, send it to the UI for modification, update it in a new request within a new transaction. This is easy with Hibernate, but impossible with JDO - transient JDO instances (decoopled from their PersistenceManager) lose their persistent identity. Note that this is not a flaw of a specific implementation but a consequence of a fundamental element of the spec itself.
So you'll need to revert to manual property copying or exposing value objects with JDO. Its persistent objects simply aren't suitable for parameter objects in a business API but rather just for implementation-internal representations of persistent state. Hibernate's persistent objects are plain Java objects with hardly any limitations, thus as flexible as... plain Java objects :-)
All things considered, there is a significant difference in approach. Hibernate is a reasonably thin wrapper on top of JDBC, bridging the gap to plain Java objects. JDO on the other hand specifies a persistent object model with special lifecycle and semantics, abstracting the relational datastore completely. JDO's approach may have advantages in certain scenarios, but I consider Hibernate's more appropriate for the majority of applications - by far.
Besides that fundamental issue, Hibernate's query language is much more sophisticated than JDOQL, and its mapping capabilities are at least on par with the best (commercial) JDO-based O/R mappers like Kodo and Lido. BTW, the latter have their own proprietary mapping formats, and a lot of proprietary query enhancements too. So you will typically be quite tied to the specific JDO implementation. The question is: Why not use Hibernate in the first place then?
Juergen -
Hibernate / JDO / CMP[ Go to top ]
- Posted by: Corby Page
- Posted on: June 09 2003 14:11 EDT
- in response to Juergen Hoeller
I evaluated Hibernate 2.0 rc2 recently, and was very impressed. It handled situations like composite primary keys very elegantly. However, it is unusable in many situations in my enterprise development environment, as are the JDO and CMP implementations I have evaluated.
The situation I need to handle in my environment ( and I have to imagine this is a common situation in large enterprises ) is that the state of an object instance can determine which table (or even which database) it is persisted to.
For example, an object instance that exists in an old date context may be persisted to an archive table. For architectural reasons, the DBA may have set up different tables for different customers, and so an object's customer ID may affect where it will be persisted. And so on.
I noticed that Hibernate had several extension points, and so I dove into the source to see if I could adapt it to my needs. Unfortunately, Hibernate is tied into the use of PreparedStatements, which allow you to dynamically change values in the WHERE clause, but not to dynamically change the database or table name.
Has anyone else used an O-R mapper that elegantly deals with this situation? -
Hibernate / JDO / CMP[ Go to top ]
- Posted by: Tero Vaananen
- Posted on: June 09 2003 15:06 EDT
- in response to Corby Page
Corby Page>>
For example, an object instance that exists in an old date context may be persisted to an archive table. For architectural reasons, the DBA may have set up different tables for different customers, and so an object's customer ID may affect where it will be persisted. And so on.
<
There is no reason for Hibernate to handle such situations. Depending on your application you might want to build another abstraction layer (e.g. DAOs) on top of Hibernate that handles these kinds of logic problems behind the scenes. -
Hibernate / JDO / CMP[ Go to top ]
- Posted by: Corby Page
- Posted on: June 09 2003 15:50 EDT
- in response to Tero Vaananen
There is no reason for Hibernate to handle such situations. Depending on your > application you might want to build another abstraction layer (e.g. DAOs) on > top of Hibernate that handles these kinds of logic problems behind the scenes.
Sadly, no level of abstraction I build on top of Hibernate will change the fact that the framework only maps a set of object attributes to one table. In my abstraction layer, I can certainly compute which table Hibernate should persist to, but I can not make Hibernate persist to it if it is not the single table that is defined in the mappings. If Hibernate offered an extension point where I could dynamically specify the table or database, then your suggestion would work.
I'm curious why you would say there is 'no reason for Hibernate to handle such situations'. It seems to me to be a valid use case for an object-relational mapping system that endeavours to support legacy data sources. -
Hibernate / JDO / CMP[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 09 2003 15:55 EDT
- in response to Corby Page
The situation I need to handle in my environment ( and I have to imagine this is a common situation in large enterprises ) is that the state of an object instance can determine which table (or even which database) it is persisted to.
>
> For example, an object instance that exists in an old date context may be persisted to an archive table. For architectural reasons, the DBA may have set up different tables for different customers, and so an object's customer ID may affect where it will be persisted. And so on.
> Has anyone else used an O-R mapper that elegantly deals with this situation?
In JDO, you can do that by creating:
1. interface Customers
2. class OldCustomers implements Customers
3. class NewCustomers implements Customers
4. Create 2 mapping files(.jdo), one for NewCustomers and other for OldCustomers.
I think you can do this in Hibernate also. -
Hibernate / JDO / CMP[ Go to top ]
- Posted by: Corby Page
- Posted on: June 09 2003 16:52 EDT
- in response to Erik Bengtson
Thanks for the suggestions. A simple inheritance solution is really unfeasible in my environment. Some classes have a different table for each month. Meaning that there are already hundreds of tables that a given instance of the class could be persisted to, and there are hundreds more in the years to come.
It is not pragmatic to maintain that many subclasses, Hibernate mappings, and / or Persistence Managers. I have other persistence requirements where the table will not be known at compile time, but can be determined dynamically.
Anyway, I was just curious if anyone knew of an O/R mapping system that could support dynamic specification of the table. -
Dynamic Data Routing with JDX O/R Mapper[ Go to top ]
- Posted by: Damodar Periwal
- Posted on: June 09 2003 21:33 EDT
- in response to Corby Page
JDX from Software Tree offers the feature of dynamically overriding the name of the default table at runtime. Currently in release 4.0, JDX is a lightweight, non-intrusive and flexible O/R Mapping technology. Free eval download available at www.softwaretree.com -
Hibernate / JDO / CMP[ Go to top ]
- Posted by: Steve Cramer
- Posted on: June 09 2003 21:54 EDT
- in response to Corby Page
<Corby Page>
Some classes have a different table for each month. Meaning that there are already hundreds of tables that a given instance of the class could be persisted to, and there are hundreds more in the years to come.
</Corby Page>
This sounds like classic horizontal partitioning, right? I'm curious why you've elected to manage this in the application tier, rather than take advantage of the partitioning capabilities in the RDBMS? Most major vendors can perform range-based partitioning (e.g., based upon date ranges) or hash-based partitioning (i.e., balanced partitions based on a hash of a particular key field or set of fields).
Of course, archived and active data are commonly separated into physically distinct databases (often on separate servers, as well), so the RDBMS facilities for handling this case transparently are much more limited.
Just curious ...
cramer -
Multiple table mapping[ Go to top ]
- Posted by: Sam Terrell
- Posted on: June 10 2003 00:03 EDT
- in response to Steve Cramer
Good database design practice tells me it would be wiser to make one table to hold them all and add fields to your indices that you would partition by. There is absolutely no way your application can handle the partitioning of the data better than the RDBMS with it's B+Tree unless you just have a bad DBMS.
The traditional reasoning for such an action was "security". Most RDBMS don't allow security to consider the value of a particular field. This is one of the major reasons that 3-Tier applications came about. If you are dealing with a legacy system, I could understand, but designing a database to have two tables with identical schema seems wrong to me both logically and practically.
If you aren't going to use the security of J2EE, then you probably shouldn't use J2EE at all. I mean, what is the point of having a middle layer if you can't implement security in it? You can graft on a .jar with the abstraction of data storage. If you have stored procedures as well, then you really gain nothing from J2EE if you don't use the security framework.
Basically, why have a third tier and break apart the table? -
Dynamic tables[ Go to top ]
- Posted by: Gavin King
- Posted on: June 09 2003 22:14 EDT
- in response to Corby Page
My feeling is that this is not at all difficult to do with Hibernate ... I think you just need to write a custom ClassPersister. I'm not sure I understand your requirements 100% though. Perhaps we could discuss it in the Hibernate mailing list. -
Dynamic table targets[ Go to top ]
- Posted by: Jonathan Ginter
- Posted on: June 11 2003 11:46 EDT
- in response to Corby Page
Hey Corby,
I've had some experience with the problem you're having now. In fact, I was forced to conceive of a new design to deal with it. I've implemented this design in the last few projects I've been involved in and it works quite well.
My current company actually has your exact problem: a data schema that dynamically creates new tables based on the day, week, month and year. And each of these new tables is dedicated to a specific customer, etc ...
For those who feel this is strange (and I don't entirely disagree with them), I should explain that we are handling gigabytes of data in real-time and our record limits would be shattered if we consolidated. That's why we were forced to fragment in the first place. We are in the process of considering options to re-architect the data layer, but in the meantime ...
The design I was talking about resolves this problem - it provides a way to dynamically determine the table at run-time using a pattern-like approach based on four base classes (I say "pattern-like" because it has not been formalized enough to be called a pattern yet). It is not part of any existing framework but I think it would meet your needs quite easily. I actually conceived of it to handle a slightly different set of problems raised by the differences in architectural priorities between the object model and the RDBMS data model - e.g., how to map a single memory object across multiple tables.
If you would like to discuss it further, you can contact me at jginter at yahoo dot com
Good luck. -
Dynamic table targets[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: June 11 2003 13:06 EDT
- in response to Jonathan Ginter
I understand this problem, it can disapear after you will install new RDBMS version. I prefer to "hidde" this kind of workarounds in UDF and Views. -
Use database table partitionning instead[ Go to top ]
- Posted by: Nicolas DASRIAUX
- Posted on: July 24 2003 04:44 EDT
- in response to Corby Page
Oracle, Sybase, SQL Server have table partitionning features.
Sometimes, a table become really too huge to fit in single physical table.
Partionning is the ability to split a single *logical* table into several *physical* table. The feature is addressed transparently by the database. From a user point of view, you only see one table.
Rows of the logical table are dispatched into physical tables following a *partitionning function*. There are two kinds of partitionning function : hash partitionning function, and range partitionning function.
I advise you to study for yourself these features.
Incidentally, (unfortunalely despised non-open-source non-free) commercial databases are that expensive because they include those kind of *enterprise class* features.
Hope it helps ... -
How Database Partionning Entry Relates To Hibernate[ Go to top ]
- Posted by: Nicolas DASRIAUX
- Posted on: July 24 2003 04:50 EDT
- in response to Nicolas DASRIAUX
This is a response to the requested feature of being able to map a class to multiple tables. A case is when you have lots of data dispatched in several tables, one for each month, for example. This design is not desirable. Partionning is a better response.
Hope it helps -
DBRouting in Persistence EdgeXtend[ Go to top ]
- Posted by: Michael Alderete
- Posted on: June 09 2003 17:19 EDT
- in response to Corby Page
The situation I need to handle in my environment ( and I have to imagine this is a common situation in large enterprises ) is that the state of an object instance can determine which table (or even which database) it is persisted to.
This is a familiar requirement, we implemented something like this for a financial services firm that stores their securities in different database tables based on the initial character of the ticker symbol (A-F in table1, G-M in table2, etc.). We call the feature Database Routing.
Michael Alderete
Persistence Software
http://www.persistence.com/ -
JDO?[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 09 2003 15:12 EDT
- in response to Juergen Hoeller
I forgot to mention that we're using Hibernate's 2.0 RCs successfully in a new project. So far, I'm really pleased with it: It simply does it what it claims to do, and it doesn't get in your way when there's no need to. And Gavin's web-based support is extremely responsive.
I've developed the Hibernate integration for the Spring Framework (BTW, the JDO integration too), thus I had to look at Hibernate's source code for details on transaction and JVM-level cache handling. The availability of the source code is worth a lot, especially for such efforts.
Juergen -
JDO?[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 09 2003 15:44 EDT
- in response to Juergen Hoeller
Last week, I did a "JDO x Hibernate benchmark" for myself, and the results shows that JDO is faster 30 or 40% faster.
My benchmark:
xPetstore Hibernate implementation
x
xPetstore JDO Libelis implementation
Even in the web environment, JDO Libelis is faster than Hibernate. Its not a true benchmark, but its enough to me. If you want, you can try for yourself, by just downloading both implementations.
Anyway, Hibernate is a very very good O/R mapper. Its a real useful project that can be used in any enterprise project. Congratulations to the Hibernate team. -
JDO?[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 09 2003 16:09 EDT
- in response to Erik Bengtson
Erik,
Where did you have the xPetstore JDO implementation from? http://xpetstore.sourceforge.net/ only shows an EJB one and a Hibernate one.
BTW, xPetstore doesn't have a dedicated business logic layer. Instead, every persistence action is coded directly in WebWork actions. As there isn't a dedicated business API with reusable business objects, it doesn't suffer from the JDO/web issue I've outlined above.
Anyway, with due respect, I absolutely doubt your numbers. Posting them without any clear backing doesn't help anyone. E.g. what was the setup of each, especially in terms of caching, lazy loading, etc? Just using the defaults can be extremely misleading: One tool may be configured to load the whole object tree into memory on each access, while the other maybe retrieves it from the cache due to its default settings. At least, I assume the same web application server and same database on the same machine for both.
As the persistence mapping is just one issue of many in a web application, no 2 reasonable persistence layers that access the same underlying database can cause a 30% to 40% difference in overall application performance - provided that they are configured similarly. The bottleneck will almost always be your database and its JDBC driver in any database-intense scenario. Persistence mapping is rather insignificant compared to this.
IMO, such a difference can only be caused by full JVM-level caching activated in Lido vs no JVM-level caching at all in Hibernate. Hibernate's caching can be finely tuned, a very important feature to be able balance between performance gain and data staleness. A further cause could be differences in various optimizations like lazy loading or batch loading of associated objects via outer joins. Hibernate supports all of them, they just need to be activated.
Finally, as always, benchmarks don't mean a lot. Every tool can be configured to outperform a competing one, whether deliberately or not. Oracle is famous for this, have a look at their DBMS comparisons.
Juergen -
JDO?[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 09 2003 16:27 EDT
- in response to Juergen Hoeller
Anyway, with due respect, I absolutely doubt your numbers. Posting them without any clear backing doesn't help anyone.
Its not a benchmark. I prefer to suggest that people interested in compare performance of Petstore implementations, download them and try. Just my numbers, not a true recognized benchmark from a known company. Even, It was numbers from "petstore tests" and not from "persistence tools tests"
Dont take this numbers to seriously, try the petstore for yourself. If you do, I would like to see your numbers. -
JDO?[ Go to top ]
- Posted by: Thomas Risberg
- Posted on: June 09 2003 17:32 EDT
- in response to Juergen Hoeller
Juergen.
> Where did you have the xPetstore JDO implementation from? http://xpetstore.sourceforge.net/ only shows an EJB one and a Hibernate one.
I assume that Erik used the one that is available from Libelis for LiDO JDO. I downloaded it from the www.libelis.com website. Look for a "LiDO and XPetStore" Whitepaper and implementation download in the "Papers" section.
--Thomas -
xPetStore[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 09:11 EDT
- in response to Juergen Hoeller
Where did you have the xPetstore JDO implementation from? http://xpetstore.sourceforge.net/ only shows an EJB one and a Hibernate one.
Eric>>>>It is available from our site (www.libelis.com, section Papers on the bootom right).
=====
> BTW, xPetstore doesn't have a dedicated business logic layer. Instead, every persistence action is coded directly in WebWork actions. As there isn't a dedicated business API with reusable business objects, it doesn't suffer from the JDO/web issue I've outlined above.
Eric>>>So it means sometimes there is a design solution versus a technical feature. That said, in one hand, 90% of our customers are using LiDO from J2EE applications and they are happy with it, because they have an intermediate layer as you said. I think this is a good design.
In another hand, even our JSP users can use our JSP Tag Lib, that is providing the same service as you describe, we manage how objects are resynchronized in a new PM.
=====
>
> Anyway, with due respect, I absolutely doubt your numbers.
Eric>>>>>So, you should test it by yourself.
I don't know Erik Bengston, but I'm encline to think he is not a liar, and he is not working for LIBeLIS.
======
Posting them without any clear backing doesn't help anyone. E.g. what was the setup of each, especially in terms of caching, lazy loading, etc? Just using the defaults can be extremely misleading: One tool may be configured to load the whole object tree into memory on each access, while the other maybe retrieves it from the cache due to its default settings. At least, I assume the same web application server and same database on the same machine for both.
>
> As the persistence mapping is just one issue of many in a web application, no 2 reasonable persistence layers that access the same underlying database can cause a 30% to 40% difference in overall application performance - provided that they are configured similarly. The bottleneck will almost always be your database and its JDBC driver in any database-intense scenario. Persistence mapping is rather insignificant compared to this.
Eric>>>>I must say you are wrong here.
The database access layer design is always doing THE big difference !
And if we tune LiDO we will get even better results.
This is our market.
We have another study will make public in few days (with source code available) where we show how LiDO compares to OJB and Castor in various environments, the results are quite interesting:
* In client-server mode, using MySQL LiDo is 20 to 50% faster.
* In client-server mode using Oracle we are up to 10 times faster.
* In J2EE using MySQL we are up to 8 times faster.
* In J2EE using Oracle we are up to 30 times faster.
Think about these figures.
>
> IMO, such a difference can only be caused by full JVM-level caching activated in Lido vs no JVM-level caching at all in Hibernate. Hibernate's caching can be finely tuned, a very important feature to be able balance between performance gain and data staleness. A further cause could be differences in various optimizations like lazy loading or batch loading of associated objects via outer joins. Hibernate supports all of them, they just need to be activated.
Eric>>>>This is the big difference with LiDO. With LiDO you get the performance without this kind of explicit tricky programming.
>
> Finally, as always, benchmarks don't mean a lot. Every tool can be configured to outperform a competing one, whether deliberately or not.
Eric>>>>>We clearly mentionned at the beginning of the PDF we deliver with the xPetStore LiDO: "this is not a benchmark".
If we do a real benchmark the LiDO benefits will be even better.
There are real benchmarks that can help prospects in making a decision, but the best benchmark is always the one you did for a specific case.
Rubis is such a valuable J2EE benchmark for instance.
Juergen>>>>Oracle is famous for this, have a look at their DBMS comparisons.
Eric>>>>Do you mean LIBeLIS is like Oracle ?
I'm pleased to see we are seen as such a big company :-))
Best Regards, Eric. -
xPetStore[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 10 2003 10:11 EDT
- in response to Eric Samson
Anyway, with due respect, I absolutely doubt your numbers.
>
> Eric>>>>>So, you should test it by yourself.
> I don't know Erik Bengston, but I'm encline to think he is not a liar, and he is not working for LIBeLIS.
I never intended to imply that Erik is a liar. It's just that he may not be aware that he compared apples with oranges, e.g. a heavily caching Lido download with a Hibernate one that doesn't even activate the JVM-level cache.
> Eric>>>>I must say you are wrong here.
> The database access layer design is always doing THE big difference !
> And if we tune LiDO we will get even better results.
> This is our market.
> We have another study will make public in few days (with source code available) where we show how LiDO compares to OJB and Castor in various environments, the results are quite interesting:
> * In client-server mode, using MySQL LiDo is 20 to 50% faster.
> * In client-server mode using Oracle we are up to 10 times faster.
> * In J2EE using MySQL we are up to 8 times faster.
> * In J2EE using Oracle we are up to 30 times faster.
>
> Think about these figures.
These figures don't mean anything if you don't mention the respective configurations. 8 times, 30 times... these can only be caused by wildly different caching settings. And heavy caching means potential staleness - we're talking about a tradeoff here. Hibernate can of course be configured to cache as heavy as you like - if one decides to accept the involved tradeoffs. If you don't mention such implications, you are misleading the readers.
So if the various persistence tools are configured comparably (i.e. similar caching, similar lazy/eager loading, etc), then I assume that one won't notice significant differences between the tools in real world scenarios. And most tools offer a lot of caching options, Lido won't be the sole king here. Let's stick to the facts: The O/R mapping strategy itself, dirty detection, etc cannot cause such differences, only caching and lazy/eager loading settings can.
> Eric>>>>This is the big difference with LiDO. With LiDO you get the performance without this kind of explicit tricky programming.
Explicit tricky programming? We're talking about caching and lazy/eager loading here, configured in Hibernate's XML mapping files. Not a single line of code has to be changed if you decide to modify these settings. Hibernate and JDO implementations are in the same league here: I don't know Lido in detail, but I assume you can configure caching and lazy/eager loading in some config file. It's just that each implementation may have different default settings.
> Juergen>>>>Oracle is famous for this, have a look at their DBMS comparisons.
>
> Eric>>>>Do you mean LIBeLIS is like Oracle ?
> I'm pleased to see we are seen as such a big company :-))
Well, are you proud of dealing with numbers the same way as Oracle? You can't be serious.
Juergen -
xPetStore[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 10:25 EDT
- in response to Juergen Hoeller
Juergen>>>>Oracle is famous for this, have a look at their DBMS comparisons.
> >
> > Eric>>>>Do you mean LIBeLIS is like Oracle ?
> > I'm pleased to see we are seen as such a big company :-))
>
> Well, are you proud of dealing with numbers the same way as Oracle? You can't be serious
Eric>>>>Right, that's why I was joking :-))) -
Don't believe this![ Go to top ]
- Posted by: Gavin King
- Posted on: June 09 2003 20:38 EDT
- in response to Erik Bengtson
Last week, I did a "JDO x Hibernate benchmark" for myself, and the results shows that JDO is faster 30 or 40% faster<
Sorry, but this is rubbish numbers ;)
You are comparing an implementation hand-optimized by a JDO vendor with an implementation that no-one in the Hibernate team had anything to do with!
xPetstore is NOT a benchmark and is not intended as such, hence caching, etc will not be optimized in the Hibernate implementation. Give me an hour with xPetstore and I can probably make it MUCH faster. But why? It is not a benchmark, it is an example app!
Shades of .NET Petstore! -
Don't believe this![ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 10 2003 03:52 EDT
- in response to Gavin King
Give me an hour with xPetstore and I can probably make it MUCH faster. But why? It is not a benchmark, it is an example app!
If you can would be nice of you. I'm evaluating Hibernate and JDO for myself, and performance is important to me.
Just curious, Why dont you use enhancement in Hibernate ? I dont care to have 2 steps compilation if performance is better.
Thanks -
umm[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 04:18 EDT
- in response to Erik Bengtson
If you can would be nice of you <
But *why*?
Anyway, you can probably do it yourself by enabling Hibernate's JCS cache and ensuring that associations are being read eagerly where appropriate.
But xPetstore is not meant as a benchmark! And performance tests of xPetstore do not measure the performance of the persistence layer only .... it is also testing webwork, velocity, etc ... if you want to compare persistence layer performance, you must *isolate* the persistence layer.
You should NOT be making financially important decisions on the basis of such unscientific nonsense.
>> Just curious, Why dont you use enhancement in Hibernate ? I dont care to have 2 steps compilation if performance is better. <
Why would performance be better?
Build-time bytecode processing is simply unnecessary. Hibernate uses the CGLIB *runtime* bytecode generation library for reflection and proxying (Hibernate doesn't usually use JDK reflection now).
Let me be quite clear: ORM performance is limited by the JDBC driver and database, NOT by the implementation of the ORM. For simple CRUD operations I expect there to be no measurable performance difference between a very good JDO implementation and Hibernate. For more difficult problems which benefit from Hibernate's support for aggregation / projection / joins in the query language, Hibernate should be considered a much better performing solution. -
JDO vs. Hibernate[ Go to top ]
- Posted by: Michael Mattox
- Posted on: June 10 2003 00:47 EDT
- in response to Juergen Hoeller
Interesting comments on JDO vs. Hibernate, I have a few comments & questions:
> Of course there are object/relational mapping implementations for JDO. So Hibernate does directly compete with those JDO products, like SolarMetric's Kodo and Libelis' Lido. Note that there isn't any open source JDO implementation that provides a similar feature set yet. It also competes with classic O/R mappers like TopLink and CocoBase, using a quite similar approach.
TriActive is gaining momentum and looks to be the first full featured open source JDO implementation. But it's not quite there yet.
> The main differences between Hibernate's approach and JDO's is the state management. Hibernate uses plain unmodified Java objects, checking for changes via reflection and specialized implementations of the standard Java collection interfaces. JDO requires bytecode-modified objects that implement its PersistenceCapable interface after the postprocessing, delegating every property access to the JDO StateManager. Thus, JDO's dirty detection is more efficient, but comes at the expense of the need for modified objects.
The "expense" of modified objects is really just a few milliseconds in the build process. Once modified, they behave exactly as regular objects.
> Unfortunately, JDO's object modification approach does involve severe drawbacks. For example, persistent objects cannot be read or written outside of an active JDO transaction (by default), as they get their values from the JDO StateManager instead of their instance variables. And even when leveraging all options, persistent objects cannot be reassociated with a new transaction of a new PersistenceManager instance.
The first part isn't true, JDO objects can be detached from the data store in which case they behave like any regular java object.
> The latter is a typical use case for web apps: Load an object in one transaction/connection, send it to the UI for modification, update it in a new request within a new transaction. This is easy with Hibernate, but impossible with JDO - transient JDO instances (decoopled from their PersistenceManager) lose their persistent identity. Note that this is not a flaw of a specific implementation but a consequence of a fundamental element of the spec itself.
> So you'll need to revert to manual property copying or exposing value objects with JDO. Its persistent objects simply aren't suitable for parameter objects in a business API but rather just for implementation-internal representations of persistent state. Hibernate's persistent objects are plain Java objects with hardly any limitations, thus as flexible as... plain Java objects :-)
You lost me. The JDO approach seems simple to me, and I use JDO objects as value objects which greatly simplifies my architecture. I retrieve a JDO object, send it to the client via JSP. Client modifies it, and on the server side I retrieve the JDO object again and then copy the properties over.
I think a huge advantage of JDO is that you're free to switch implementations without changing your code. Yes I do use a few vendor extensions, but it's a simple change in a properties file or the JDO metadata. I really like coding to a standard API. I cannot say anything bad about Hibernate, I haven't used it. If it were JDO compliant I'd be using it on my projects.
Michael -
JDO vs. Hibernate[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 10 2003 06:24 EDT
- in response to Michael Mattox
Michael,
> TriActive is gaining momentum and looks to be the first full featured open source JDO implementation. But it's not quite there yet.
I know TJDO, and I agree - it just isn't quite there yet, it's still pretty bare-bones in terms of meet-in-the-middle mapping etc.
> The "expense" of modified objects is really just a few milliseconds in the build process. Once modified, they behave exactly as regular objects.
No, they don't: They are tied to their JDO PersistenceManager and its transaction as long as they aren't explicitly made transient. And then, they can't be reassociated with a new PersistenceManager for an update in the course of a new request.
> The first part isn't true, JDO objects can be detached from the data store in which case they behave like any regular java object.
Notice the "(by default)" in my original posting: This indicates JDO's intended programming model. Persistent objects have to be made transient explictly (not necessary with Hibernate), and they lose their persistence semantics then.
> You lost me. The JDO approach seems simple to me, and I use JDO objects as value objects which greatly simplifies my architecture. I retrieve a JDO object, send it to the client via JSP. Client modifies it, and on the server side I retrieve the JDO object again and then copy the properties over.
That's exactly what I meant: You need to copy properties with JDO, or use value objects in the first place. How do you detect changes that someone else applied to the original object in the meantime, i.e. avoid lost updates? On the other hand, you can simply call session.update(myObjectComingBackFromTheUI) with Hibernate, leveraging Hibernate's versioning and timestamping support to detect staleness.
Note that with Hibernate, "optimistic transactions" can span multiple sessions and thus multiple requests easily, in contrast to JDO's "optimistic transactions" that just defer SQL generation to the original transaction's commit.
> I think a huge advantage of JDO is that you're free to switch implementations without changing your code. Yes I do use a few vendor extensions, but it's a simple change in a properties file or the JDO metadata. I really like coding to a standard API. I cannot say anything bad about Hibernate, I haven't used it. If it were JDO compliant I'd be using it on my projects.
I basically agree regarding coding to standard APIs, and I don't mind having JDO implementations as persistence options. But Hibernate really offers a lot beyond standard JDO, e.g. the reassociation programming model, and very sophisticated querying capabilities. And personally, I prefer a powerful and production-ready open source solution to the choice between multiple commercial implementations of a "standard" that even includes conceptual flaws.
Juergen -
yes, but[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 06:56 EDT
- in response to Juergen Hoeller
Hibernate simply requires one or more properties in the object that make up its identity, so these can be used to identify the instance on reassociation. <
lets not say "requires", for risk of misinterpretation ;)
Hibernate "lets" you (optionally) have a property that is mapped to the primary key value. If you choose to provide such a property, the "reassociation" architectural model becomes possible. Otherwise you can use Hibernate with the entity bean / JDO model. -
JDO Optimistic Transactions[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 07:16 EDT
- in response to Gavin King
This is not correct. JDO O/R vendors implement optimistic locking using traditional version or timestamp columns just like non-JDO O/R mappers. There is no reason why an optimistic JDO transaction cannot span multiple requests.
<
Hmmmmmm I'm not sure if this is quite right. I am inclined to defer to your superior knowledge of JDO, but the impression I got from reading stuff over at JDO central (and from the JDO spec itself) is that to do this would require the single PersistenceManager instance (equivalent of a Hibernate Session instance) to span multiple user requests. This is equivalent to a long-lived Hibernate Session with connect() / disconnect().
What Juergen is talking about is a multitiered architecture with, say, Hibernate in a session bean. The session bean passes serialized POJOs back to the web tier. The web tier passes them (modified) back down to the EJB tier later. A different Session instance handles each user request. Very, very scalable and performant approach :)
My understanding is that this is not possible in JDO. It *would* be possible if you were all in one process (say, in tomcat) and you were happy to keep the PersistenceManager open with objects sitting in its cache over multiple user requests. (The JDO PM is serializable, presumably, to allow this to work?)
But the fact that the web tier is passing back *different* (serialized) instances breaks stuff (I _think_).
Both designs are possible in Hibernate but the one supported by JDO is certainly the least popular approach. It is much more popular to use the 1 Session per user request / Session.update() approach.
I think we are not mistaken here, but please correct us if we *are*, since I had counted it as a big disadvantage of JDO....
peace -
JDO Optimistic Transactions[ Go to top ]
- Posted by: David Tinker
- Posted on: June 10 2003 07:41 EDT
- in response to Gavin King
Hi Gavin
"require the single PersistenceManager instance (equivalent of a Hibernate Session instance) to span multiple user requests"
You are correct. I was assuming a stateful session bean or http session with a PM kept open. Sorry about that. My misunderstanding.
"The session bean passes serialized POJOs back to the web tier. The web tier passes them (modified) back down to the EJB tier later. A different Session instance handles each user request. My understanding is that this is not possible in JDO"
You can do this in JDO. You need to use application identity so that the primary key is in the transient instance fields. When the transient instance comes back you look up the managed JDO instance using the PK and copy in the data. You could add your own version field for stale checking or use vendor specific features for this (we support mapping the version or timestamp column to a field in the class much like app identity).
I agree that it would be really nice if JDO supported reassociating transient instances with a PM as this would avoid the need to manually copy the data. This is very likely to be in JDO 2.0.
Remember that it is also popular to decouple the clients from the server completly by not exposing model objects to the client. With the DTO pattern the data is copied to/from use-case specific data transfer objects making this whole point moot.
I think that there is space for different approaches to persistence. The large number of O/R mappers and JDO O/R implementations out there shows this. The JDO standard is likely to grow and include things from other implementations.
Cheers
David
JDO Genie - High Performance JDO for JDBC -
JDO Optimistic Transactions[ Go to top ]
- Posted by: David Tinker
- Posted on: June 10 2003 06:59 EDT
- in response to Juergen Hoeller
Hi Juergen
"Note that with Hibernate, "optimistic transactions" can span multiple sessions and thus multiple requests easily, in contrast to JDO's "optimistic transactions" that just defer SQL generation to the original transaction's commit. "
This is not correct. JDO O/R vendors implement optimistic locking using traditional version or timestamp columns just like non-JDO O/R mappers. There is no reason why an optimistic JDO transaction cannot span multiple requests.
Cheers
David
JDO Genie - High Performance JDO for JDBC -
Hibernate with ODBMS[ Go to top ]
- Posted by: yves yang
- Posted on: July 10 2003 19:35 EDT
- in response to Michael Mattox
Hi all,
Can an application based on Hibernate work with object database ? Do you think the better solution to reach the better performance isn't using OR mapping at all ? There a benchmark between the better OR mapping - TopLink with Versant:
http://www.techmetrix.com/products/publiDetail.php?code=rep03021¤tLanguage=E
yves yang -
JDO?[ Go to top ]
- Posted by: Oz Kologlu
- Posted on: June 10 2003 00:56 EDT
- in response to Juergen Hoeller
I agree with you on most of comments bar one, which is that there are no open source JDO implementations that provide a similar feature set.
I have been using TJDO ( Triactive ) http://tjdo.sourceforge.net/ and it is in pretty good shape for a JDO implementation.
OJB in catching up in the JDO stakes though they are more in line with the ODMG spec ( which JDO is based on ) and their own richer persistance broker API.
In truth, I think for JDO leaves too much out of the spec and relies on vendor extensions to fill in the gaps - which then defeats the purpose of a standard!
Oz -
Fatal flaw or remediable blemish?[ Go to top ]
- Posted by: David Ezzio
- Posted on: June 10 2003 01:43 EDT
- in response to Juergen Hoeller
The latter is a typical use case for web apps: Load an object in one transaction/connection, send it to the UI for modification, update it in a new request within a new transaction. This is easy with Hibernate, but impossible with JDO - transient JDO instances (decoopled from their PersistenceManager) lose their persistent identity. Note that this is not a flaw of a specific implementation but a consequence of a fundamental element of the spec itself.
Hi Juergen,
I have been wondering about this point for some time, and since you seem familiar with both Hibernate and JDO, you may be just the fellow to answer it.
As someone else noted, in JDO, once the data objects become detached, they behave like POJOs. The enhancement added code is still there in the class, but its effects are disabled (except for usually negligible performance impact.) On the trip back from the client, it would seem to me that the same techniques that Hibernate uses to match up POJOs with the unmodified objects could be used to match up JDO's detached data objects with their persistent counterparts. In short, JDO could do what it does now with attached data objects, and at the same time, be improved to handle detached data objects better by learning from Hibernate. Does that make sense to you?
On another note, as I recall from my one short look at Hibernate, it does not have transparent persistence. To use a persistent reference to another persistent object, you have to call the Hibernate API to materialize the reference. Is that correct? It strikes me that that is a really big advantage for JDO. Attached data objects have transparent persistence. Any persistent objects that they refer to materialize magically, making an attached data object act very much like a plain old Java object. Are there some advantages to the Hibernate approach in this regard that I am ignorant of? Or should I have spent a little more time looking at Hibernate?
David Ezzio -
correction[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 01:54 EDT
- in response to David Ezzio
as I recall from my one short look at Hibernate, it does not have transparent persistence. To use a persistent reference to another persistent object, you have to call the Hibernate API to materialize the reference <
Hibernate is every bit as transparent as JDO. You certainly do NOT have to call any API methods to navigate the object graph.
>> On the trip back from the client, it would seem to me that the same techniques that Hibernate uses to match up POJOs with the unmodified objects could be used to match up JDO's detached data objects with their persistent counterparts. In short, JDO could do what it does now with attached data objects, and at the same time, be improved to handle detached data objects better by learning from Hibernate. Does that make sense to you? <
JDO could certainly be improved to add this feature. Note that this is a very useful feature and most Hibernate applications are architected to take advantage of it. -
Hibernate Transparent?[ Go to top ]
- Posted by: David Tinker
- Posted on: June 10 2003 07:18 EDT
- in response to Gavin King
Hi Gavin
"Hibernate is every bit as transparent as JDO. You certainly do NOT have to call any API methods to navigate the object graph."
How does Hibernate achieve this?
For others on this thread: JDO enhances the persistent classes to trap all field read and writes. This it easy to fetch data as it is accessed and to track dirty changes.
Cheers
David -
CGLIB[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 07:28 EDT
- in response to David Tinker
How does Hibernate achieve this? <
As I said: CGLIB runtime bytecode generation.
Where have you been?!
We have been using this technology with great success for almost a year now. Users are very happy with it. No annoying build-time class mangling.
Works beautifully :) -
CGLIB[ Go to top ]
- Posted by: David Tinker
- Posted on: June 10 2003 07:56 EDT
- in response to Gavin King
Hi Gavin
" >> How does Hibernate achieve this? <As I said: CGLIB runtime bytecode generation.
Where have you been?!"
I know this bit. I was looking for specifics on exactly what you generate to achieve transparent fetching of a reference on navigation. I am interested to know how this is done and thought I could get a quick answer.
"No annoying build-time class mangling."
The JDO spec does not mandate doing bytecode enhancement at compile time. It can be done at runtime. The spec defines how it should be done so all vendors are the same.
Doing it at compile time has important benefits:
a) You can easily decompile the enhanced classes to see for yourself just how trivial the bytecode enhancement process is.
b) The server starts up quicker.
This is something that really gets to me about all the runtime aspect hype - people complain about the trivial JDO bytecode enhancement (typically done at compile time) but are happy to accept large scale runtime bytecode work!
Cheers
David -
CGLIB[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 08:34 EDT
- in response to David Tinker
I was looking for specifics on exactly what you generate to achieve transparent fetching of a reference on navigation. I am interested to know how this is done and thought I could get a quick answer. <
K, sorry, apologies for being flippant.
The approach is _proxying_, not field access interception. So with CGLIB it is similar to what you would use if you were trying to use a java.lang.reflect.Proxy. Unlike a JDK Proxy, however, CGLIB lets me proxy an actual concrete class, not just a collection of interfaces.
I guess I slightly overstate the case. The JDO field interception approach is *slightly* more transparent to the user. With Hibernate, you might need to use Hibernate.getClass(foo) instead of foo.getClass() if you don't want to get hold of some annoying generated subclass of Foo. Also, CGLIB proxies don't work for final classes.
Of course, in real Hibernate applications, you never really see code like Hibernate.getClass() (I never once used this feature myself) and it is extremely rare to meet a final POJO - so in practice it is all _very_ transparent.
CGLIB is an amazingly useful library, and I expect to see it start popping up in AOP frameworks, etc. -
correction[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 09:20 EDT
- in response to Gavin King
as I recall from my one short look at Hibernate, it does not have transparent persistence. To use a persistent reference to another persistent object, you have to call the Hibernate API to materialize the reference <>
> Hibernate is every bit as transparent as JDO. You certainly do NOT have to call any API methods to navigate the object graph.
Eric>>>>>>This has been discussed a lot within the JDO Expert Group.
Fully transparent persistence CANNOT be reached by runtime reflection or dynamic proxies. It must be intrusive in the code somewhere.
Best Regards, Eric. -
correction[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: June 10 2003 17:45 EDT
- in response to Eric Samson
Eric>>>>>>This has been discussed a lot within the JDO Expert Group.
>Fully transparent persistence CANNOT be reached by runtime reflection or >dynamic proxies. It must be intrusive in the code somewhere.
It is no way to implemet "Fully transparent persistence" in JAVA at this time, JDO enhancer workaround does not help too, it is a very nice experiment, but
It has nothing more transparent than hibernate for DB developers and we do not
need this kind of transparence, we are not going to migrate from RDMS to flat files.
I will help to implement JDO API for hibernate if community will find it usefull, but nobody needs it at this time. Hibernate is a free and open source framework, It does not need to implement "transparent persistence standard" for propoganda, source code is the best propoganda for Hibernate. -
correction[ Go to top ]
- Posted by: Cedric Beust
- Posted on: June 10 2003 18:18 EDT
- in response to Juozas Baliuka
Funny. Since when is being called a french company an insult or FUD - in particular if you *are* a french company?
However, the rumor that we hardly ever take showers is pure FUD.
--
Cedric
http://beust.com/weblog -
Fatal flaw or remediable blemish?[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 10 2003 06:36 EDT
- in response to David Ezzio
On the trip back from the client, it would seem to me that the same techniques that Hibernate uses to match up POJOs with the unmodified objects could be used to match up JDO's detached data objects with their persistent counterparts. In short, JDO could do what it does now with attached data objects, and at the same time, be improved to handle detached data objects better by learning from Hibernate. Does that make sense to you?
Well, as Gavin has already noted, that would certainly be possible. But to achieve that, the JDO spec would have to change its persistent identity concept radically. Hibernate simply requires one or more properties in the object that make up its identity, so these can be used to identify the instance on reassociation.
With JDO on the other hand, only the PersistenceManager knows the primary key of a persistent object - after being made transient, the object's persistent identity is lost. Even if you explicitly map a primary key column to a property of the object, a new PersistenceManager will not (and isn't even allowed to) recognize it on reassociation - by design. Again, the problem is the spec's lifecycle model.
Juergen -
JDO Identity[ Go to top ]
- Posted by: David Tinker
- Posted on: June 10 2003 07:11 EDT
- in response to Juergen Hoeller
Hi Juergen
"With JDO on the other hand, only the PersistenceManager knows the primary key of a persistent object - after being made transient, the object's persistent identity is lost."
This is not correct. The JDO spec supports application identity where the identity of the instance is visible in one or more primary key fields in the class. This is an optional feature that is supported by all the JDO O/R vendors I know of. This makes it easy to get a JDO managed instance for a transient instance returning from a GUI.
I agree that it would be nice if a transient instance could be reassociated with a PM automatically. This would save the field copies. This feature will most likely be in JDO 2.0.
JDO Genie provides an alternate approach. We support PersistenceManager's in different VMs to the JDO Genie server. The client uses the normal JDO API just like server side code. All communication with the server is hidden. Only changes are sent to the server on commit making this very efficient. No need to serialize large object graphs back to the server for diffing. The code using JDO runs unchanged on the client or the server.
Cheers
David
JDO Genie - High Performance JDO for JDBC -
Aha[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 07:23 EDT
- in response to David Tinker
I agree that it would be nice if a transient instance could be reassociated with a PM automatically. This would save the field copies. This feature will most likely be in JDO 2.0.<
Ah, beautiful, you confirmed our understanding in your second post. I *thought* so. So anyway, Juergen is correct and JDO 1.x does not support this programming model. Clearly JDO 2.0 will need to, because this is how most of our users want to work.
>> JDO Genie provides an alternate approach. We support PersistenceManager's in different VMs to the JDO Genie server. The client uses the normal JDO API just like server side code. All communication with the server is hidden. Only changes are sent to the server on commit making this very efficient. No need to serialize large object graphs back to the server for diffing. The code using JDO runs unchanged on the client or the server. <
But again, this is not the architectural model we described above. The whole *point* is that you want to be able to do business logic and interaction with the persistence API in a different process (machine, even) to the presentation logic. So JDO Genie doen't help us much, by the looks.... -
Aha[ Go to top ]
- Posted by: David Tinker
- Posted on: June 10 2003 08:07 EDT
- in response to Gavin King
Hi Gavin
"So anyway, Juergen is correct and JDO 1.x does not support this programming model. Clearly JDO 2.0 will need to, because this is how most of our users want to work."
As I mentioned in my post JDO *does* support this programming model. Use application identity so the primary key is in the transient instance, look up the managed instance on return and copy in the data. This is not as convienient as automatic re-association but is a JDO portable way to achieve this.
Cheers
David -
Aha[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 10 2003 08:35 EDT
- in response to David Tinker
David
> As I mentioned in my post JDO *does* support this programming model. Use application identity so the primary key is in the transient instance, look up the managed instance on return and copy in the data. This is not as convienient as automatic re-association but is a JDO portable way to achieve this.
The whole point of my argument is that the you need copy the properties into the freshly loaded instance - manually! This can be extremely annoying even with one single object but especially when talking about object trees. One has to create quite a lot of unnecessary, repetitive code for this.
Regarding application identity: I'm aware of that option. But what is it worth when a new PersistenceManager still doesn't accept a decoupled instance as persistent object including modified contents? Just getting the ID for being able to requery the object isn't comfortable enough, IMO.
Concerning multiple tiers: A distributed architecture is the case where not even keeping the PersistenceManager instance between request helps. But even in the local case, a dedicated business tier with a clear API is a very important best practice. Such a tier could be modelled as local Session Beans, although I prefer a well-architected POJO layer by far.
As such a business tier should be as stateless as possible for maximum scalability, and not web-dependent of course, it can and should not put anything in a (HTTP) session. With Hibernate, this isn't necessary, so I don't see a reason why one should break the architecture with JDO PersistenceManager instances in a session - just for being able to reassociate persistent objects!
Juergen -
JDO Identity[ Go to top ]
- Posted by: Robin Roos
- Posted on: June 10 2003 07:53 EDT
- in response to David Tinker
In JDO 1.0 an instance of an "enhanced" class is compatible at the serialization level with the "unenhanced" class. I believe this is the reason hy transient JDO instances loose knowledge of their identity.
Here's the way I think its going to go in JDO 2.0 - this is certainly what I'm promoting: On being made transient or "disconnected" a persistent instance will remember its JDO identity and its version. (Version would be a new concept to support long-lived optimistic transactions that span PersistenceManager sessions, and a version object would be completely opaque.) We will then provide reconnect semantics by which a transient instance can be attached to a new PersistenceManager. If that takes place within the context of an optimistic transaction, the Version "known" by the instance will be used to undertake the optimistic concurrency checks.
This capability will improve JDO's applicability to the architectural scenarios you describe. JDO is often used there, but explicit support for disconnection/reconnection and long-lived optimistic transactions will certainly help.
The support for such a strategy requires two new methods (or method groups) on PersistenceManager: disconnect(Object)/disconnectAll(Collection), reconnect(Object)/reconnectAll(Collection). It also requires the implementation of opaque versions, and placeholders in the enhancement process for an object to know its identity and version.
I believe these will be easy to implement. The sacrifice might be that persistence instances can no-longer be serializaed into "unenhanced" classes, or that after doing so they could not be transparently reconnected to a new PersistenceManager.
What I have describes is only my private proposal in this area, but I'm open to any comments or criticisms from this forum.
Kind regards, Robin. -
JDO Identity[ Go to top ]
- Posted by: Thomas Risberg
- Posted on: June 10 2003 11:06 EDT
- in response to Robin Roos
Robin,
> Here's the way I think its going to go in JDO 2.0 - this is certainly what I'm promoting: On being made transient or "disconnected" a persistent instance will remember its JDO identity and its version. (Version would be a new concept to support long-lived optimistic transactions that span PersistenceManager sessions, and a version object would be completely opaque.) We will then provide reconnect semantics by which a transient instance can be attached to a new PersistenceManager. If that takes place within the context of an optimistic transaction, the Version "known" by the instance will be used to undertake the optimistic concurrency checks.
>
This looks like a move in the right direction. In my opinion, beeing able to disconnect and re-connect a persistent object is critical.
I would also like to see some changes that make it easier to work with ApplicationIdentity. I am currently forced to inplement an additional class for the primary key, even if the key is a plain Integer or Long. This doubles the number of classes and seems to go against the transparency of JDO persistence.
Regards,
Thomas -
JDO Identity[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 11:26 EDT
- in response to Thomas Risberg
I would also like to see some changes that make it easier to work with ApplicationIdentity. I am currently forced to inplement an additional class for the primary key, even if the key is a plain Integer or Long. This doubles the number of classes and seems to go against the transparency of JDO persistence.
Eric>>>>Most JDO Implementations alre -
JDO Identity[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 11:28 EDT
- in response to Thomas Risberg
I would also like to see some changes that make it easier to work with ApplicationIdentity. I am currently forced to inplement an additional class for the primary key, even if the key is a plain Integer or Long. This doubles the number of classes and seems to go against the transparency of JDO persistence.
>
Eric>>>>>Ooops.
Many JDO implementations already provide a mechanim that automatically generates the ObjectID class for you.
Best Regards, Eric. -
Why not use Hibernate in the first place then?[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 08:45 EDT
- in response to Juergen Hoeller
few reasons to use LiDO first instead of Hibernate:
1. Performance
2. Respect a true standard
3. Performance
4. Data source portability
5. Performance
6. Tools (GUI mapping tool, business browser, ...)
7. Performance
8. Real transparent persistence
and much more.
Best Regards, Eric. -
getting squeezed out of the market.[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 09:14 EDT
- in response to Eric Samson
Okay then, if you are going to post rubbish like this:
>> A few reasons to use LiDO first instead of Hibernate: <
ie. a few unsubstantiated claims that simply don't stand up to scrutiny.
>>1. Performance <
Absolute garbage - where are your results to show this. Do you REALLY want to go up against us in a fair benchmark? c'mon, do you want to get into that? I will write an app and send it to you to port to JDO. Then we will see.
Or do you have a *single* banchmark result at all to show?? Care to share?
Hibernate will beat ANY current JDO implementation for nontrivial problems. For example, how well does you JDO app perform doing:
select count(customer)
from Customer customer
where customer.name like :name
and customer.version = (
select max(c.version) from Customer c where c.cid=customer=cid
)
>>2. Respect a true standard<
Name a single large vendor (IBM, Sun, etc) or mature commercial product that implements this "true" standard.
>>3. Performance<
>>4. Data source portability<
Hibernate supports: Oracle, DB2, MySQL, PostgreSQL, Sybase, SAP DB, HypersonicSQL, Microsoft SQL Server, Informix, FrontBase, Ingres, Progress, Mckoi SQL, Pointbase and Interbase.
>>5. Performance<
>> 6. Tools (GUI mapping tool, business browser, ...) <
XDoclet? Middlegen? AndroMDA?
>> 7. Performance<
>>8. Real transparent persistence <
In *what* way is Hibernate nontransparent??!!
I was really enjoying this civil discussion until this moment. Now I'm annoyed. I guess I shouldn't be. The reason for this kind of behaviour is that LiDO is being squeezed dry in the marketplace by OSS projects like Hibernate and OJB and, if this behavior is any indication, will presumably go under. I guess you guys KNOW that we have more users than the JDO vendors put together and realize what that means for your bottom lines.
For the information of other readers, Eric Samson is the president of LIBeLIS, "a privately held french company founded in 2000." He wants you to entrust your enterprise infrastructure to his product, while simultaneously induging in absurd claims like this.
Apologies if this post is somewhat intemperate. I am pissed off. I *always* try to keep my criticisms of other technology _fair_ and _accurate_. -
out of the market ?[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 09:40 EDT
- in response to Gavin King
Gavin
I must admit I hesitated between answer you and stopping to discuss with you. I really dislike your tone.
Each time we speak about O/R mapping it seems you know everything about everything and all other are dumbs.
It is normal you are proud of your product but please don't use this style.
There are other products that are at least as interesting as your one, with different approaches and different benefits for customers.
Having a standard is definitely a nice thing for customers, it is strange you can't understand that.
Now you attack LIBeLIS in a very unfair/inelegant way:
* we do have real "customers", while you just have "users"
* we have investors on board
* our chairman of the board is the former General Manager of BEA in Southern Europe and before that General Manager of Sybase in Southern Europe
* we recently announced a partnership with Sybase
* JDO not backed by big names: I think you are in a good position to know small organizations can provide good technologies, aren't you ?
Best Regards, Eric. -
Hibernate JDO benchmark[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 09:46 EDT
- in response to Gavin King
Hibernate will beat ANY current JDO implementation for nontrivial problems. For example, how well does you JDO app perform doing:
>
> select count(customer)
> from Customer customer
> where customer.name like :name
> and customer.version = (
> select max(c.version) from Customer c where c.cid=customer=cid
> )
You can send me a benchmark if you want, but please not something like the code before, we need a real Java application, with a business layer and so on.
Another option would be you port the Rubis Benchmark to Hibernate. This public open source benchmark has been designed to compare JSP + JDBC, JSP + Sessions + JDBC and JSP + Sessions + Entities.
This benchmark will be availbale soon with a JDO facet.
What do you think ?
Best Regards, Eric -
out of the market[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 09:48 EDT
- in response to Gavin King
2. Respect a true standard<>
> Name a single large vendor (IBM, Sun, etc) or mature commercial product that implements this "true" standard.
Eric>>>>Its is really disappointing to see an open source organization relaying the same kind of FUD that big names are using.
We already have 12 vendors implementing the standard.
And some big names are really open to recommend LiDO to their customers.
Best Regards, -
support from big names[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 09:50 EDT
- in response to Gavin King
2. Respect a true standard<>
> Name a single large vendor (IBM, Sun, etc) or mature commercial product that implements this "true" standard.
>
JDO is a true standard, with an active community.
Maybe big names didn't implement it right now, but they all voted for JDO when the standard has been officially approved in March 2002.
Best Regards, -
support from big names[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 10 2003 10:05 EDT
- in response to Eric Samson
2. Respect a true standard<<
> >
> > Name a single large vendor (IBM, Sun, etc) or mature commercial product that implements this "true" standard.
> >
>
> JDO is a true standard, with an active community.
> Maybe big names didn't implement it right now, but they all voted for JDO when the standard has been officially approved in March 2002.
>
Seems that JBoss is creating their own JDO implementation.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jboss-persistence/src/main/org/jboss/persistence/jbossdo -
support from big names[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: June 10 2003 10:36 EDT
- in response to Eric Samson
JDO is a true standard, with an active community
Hibernate is a standard too, with an active opensource community and I prefer
*open* standards like Hibernate. Try to implement HQL for your product, I am sure it will be very popular too.
"The nice thing about standards is that there are so many to choose from."
Peter Eisentraut -
Hibernate a standard[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 10:50 EDT
- in response to Juozas Baliuka
Hibernate certainly has a lot of users, it is open source, but it is not a standard like JDO for different reasons:
* there is no specification
* there is no test suite for compliance
* there is only one organization that develop Hibernate
* there is no process describing how the product will evolve
While JDO is defined under the JCP (Java Community Process) that is an OPEN process.
Best Regards, -
Hibernate a standard[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: June 10 2003 11:45 EDT
- in response to Eric Samson
Hibernate certainly has a lot of users, it is open source, but it is not a standard like JDO for different reasons:
>
> * there is no specification
So what? (see my comments above)
> * there is no test suite for compliance
Compliance for what? Is this #1 all over again? How can you have a compliance test suite for a spec you are not adhering to in the first place?!?
Besides, there is a *huge* test suite to ensure it does what it says it does. This allows for rapid development of new features without the fear of breaking existing features.
> * there is only one organization that develop Hibernate
What organization is that? Java developers? If my choices are an proven OSS solution with a very active community or a commercial product from a relatively young company I have never heard of, I know which product I will choose. This is no knock on LiDo (I have never used it). But even if I jump into bed with a product that adheres to the JDO spec, how do I know you will be around tomorrow for upgrades or to support me? Specs are great, but they are critical for software adopting.
> * there is no process describing how the product will evolve
Sure there is. Hibernate is driven by features requested by real world users. And that is exactly how I want my product to evolve. I don't want to wait for a board to vote next year for features I want now.
If you read the Hibernate forums, the conversations often go like this (I should say *went* like this - there are increasingly fewer new features requested as Hibernate is pretty feature-rich):
User 1: Have you ever thought about xxx? I want to do xxx for my project, but I can't find a way to do this with Hibernate?
User 2: Same here? I was thinking about doing xxx last week but wasn't sure if this was possible.
Gavin: Yeah. I have been thinking about how we could implement this in Hibernate. Now that some others want this. I will take a look at this and it should be in the CVS head tomorrow.
Good stuff!
Ryan
P.S. In this midst of all of this benchmarking crap and bickering, I forgot to say congrats to the Hibernate team on a great product! -
Hibernate a standard[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 10 2003 12:05 EDT
- in response to Ryan Breidenbach
Discussion like this is the way to evolution. Get the positive aspects of both technologies in this discussion and turn it in the best technology to persist data.
Remember, do it healthly. -
data source support[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 09:55 EDT
- in response to Gavin King
4. Data source portability<>
> Hibernate supports: Oracle, DB2, MySQL, PostgreSQL, Sybase, SAP DB, HypersonicSQL, Microsoft SQL Server, Informix, FrontBase, Ingres, Progress, Mckoi SQL, Pointbase and Interbase.
Eric>>>>We support all of them but SAPDB and FrontBase, (we also Cloudscape).
But we also support non-RDBMS like ODBMS, Unisys or files on disk and we will support more of them soon.
This is what I mean by portability.
Best Regards, Eric. -
data source support[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: June 10 2003 10:19 EDT
- in response to Eric Samson
Hibernate is a very pragmatic O/R mapping implementation it is designed by developers and for developers, but it is not "Transparent Persistence" and
it is not used to save objects to file, It does one thing good for database developers, try it for free. -
data source support[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 10 2003 10:56 EDT
- in response to Juozas Baliuka
Hibernate is a very pragmatic O/R mapping implementation it is designed by developers and for developers, but it is not "Transparent Persistence" and
> it is not used to save objects to file, It does one thing good for database developers, try it for free.
That's a matter of definition. Hibernate is about "Transparent persistence to relational databases" - the thing that most developers are concerned with. Noone disputes the fact that JDO has its merits for other datastores like OODBs or even flat files in restricted environments, although issues like the reassociation drawback still apply.
So I'd rather state it like this: Which solution is more appropriate for common O/R mapping requirements, faced by >90% of typical J2EE applications? Note that we're talking about the basic approach here, not about some current product limitations or implementation details.
Juergen -
Let's roll the dice[ Go to top ]
- Posted by: David Ezzio
- Posted on: June 10 2003 10:06 EDT
- in response to Gavin King
Eric and Gavin,
Intemperate remarks even when you're angry does not help anyone. I am sure that whole world would love to see a benchmark that compared Lido to Hibernate. Later we might extend it to some other "players" as well. Clearly the results will not be trivial. Two of the good things that could come out of it is that both Lido and Hibernate will become better after the comparison.
So let's talk about benchmarks and get an idea of what would be reasonable. Do we want to start with a web app or an app that uses EJBs?
I disagree with Gavin that we have to isolate the persistence layer. Instead, I think we can just publish the results for all kinds of hardware/db/JDBC driver configurations and encourage people to try the benchmark in their test environment. As Eric says it is the test that you run yourself that means the most.
So two requirements, I think. The benchmark should be open source, and it should be distributed with Ant scripts. Also rather than one big test, I think several small tests would be more meaningful and more easily supplemented with additional tests as we think of them.
David Ezzio -
suitably chastened[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 10:35 EDT
- in response to David Ezzio
Intemperate remarks even when you're angry does not help anyone. <
Sure, please forgive from my comments of a nfew minutes ago :(
>> So let's talk about benchmarks and get an idea of what would be reasonable. Do we want to start with a web app or an app that uses EJBs? <
EJBs won't be so good since I would choose an architecture that is messy to implement in JDO. We would have a natural advantage. Anyway, the webapp would remove some of the other overheads and let us concentrate on the ORM.
>> I disagree with Gavin that we have to isolate the persistence layer. <
The reason I think it needs to be isolated is this:
For simple CRUD operations, the difference between various ORM implementations is likely to be so small as to be difficult to measure even in a fully isolating benchmark (I've never really been able to reliably measure the "overhead" of Hibernate - all I know is its smaller than measurment error). If we really want to pick up on some differences, we need to remove all the other overheads.
Well, this depends upon what we are benchmarking. The first decision is this:
IMO, a mistake that is easy to make when benchmarking ORMs is to rely too heavily on the process-level cache. This is unrepresentative because, in real heavy duty applications
(a) you don't read the same data over and over again like benchmarks do
(b) you generally don't run on a single machine, so you need to be fussy about transaction isolation impact of the process-level cache
It is VERY easy to config an ORM to scream through a benchmark reading most data out of its cache. I'd say this is undesirable, but we would need to decide upon that.
So, if we just want to measure cache implementations, I'd say we *would* be able to spot some differences with a whole application with UI layer etc. But I think that these results would be misleading. I would much rather see an isolating benchmark - and then run it against ORM solutions with caching turned down to what would be acceptable in a clustered environment, with very large datasets. (And then turn it back up, if we like.)
Is that clear, or am I making no sense?
My other reason is that we would want tests for various inheritance mapping strategies, "sizes" of classes, etc ... so implementing a whole app could simply get out of hand...
Thoughts? -
Oh no, not another benchmark[ Go to top ]
- Posted by: Cedric Beust
- Posted on: June 10 2003 10:45 EDT
- in response to David Ezzio
Intemperate remarks even when you're angry does not help anyone. I am sure that whole world would love to see a benchmark that compared Lido to Hibernate. Later we might extend it to some other "players" as well. Clearly the results will not be trivial. Two of the good things that could come out of it is that both Lido and Hibernate will become better after the comparison.
Allow me to describe the next few weeks:
- A Benchmark will be published
- JDO (or Hibernate) will publish faster results
- Hibernate (or JDO) will contest them and publish even faster results after a few tweaks
- A long thread will ensue
- At the end of which we will all recognize that benchmarks are not that important and that we need to compare both technologies on all their merits and not just raw performance.
--
Cedric
Time traveler since 2038 -
Oh no, not another benchmark[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: June 10 2003 10:50 EDT
- in response to Cedric Beust
- At the end of which we will all recognize that benchmarks are not that important and that we need to compare both technologies on all their merits and not just raw performance.
Amen!
> --
> Cedric
> Time traveler since 2038
Thanks for the chuckle, Cedric. -
benchmarks[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 10:58 EDT
- in response to Cedric Beust
Hi Cedric
You're right. Anyway, you know, as me, each time you meet a prospect, the first question is always: "do you have a benchmark ?".
In fact, having a benchmark with official measures is not really helpful.
What is importnat is to have a benchmark structure, with open source code, allowing any prospect to change the code, adapt it to its own model and constraints, and run it on its home DBMS/OS/JDK...
Best Regards, -
Hibernate or LiDO[ Go to top ]
- Posted by: Christian Sell
- Posted on: June 10 2003 12:25 EDT
- in response to Eric Samson
It is my perception, both from this thread and from other appearances, that LiDO is heavily relying on performance claims in their marketing. That alone has always made them incredible for me. The reasons for this have been well stated in this thread.
The way their CTO has involved himself in a rather unprofessional discussion on a thread dedicated to another product has not remedied that distrust.
Having said that, I dont think Hibernate or LiDO/JDO are stealing anything from eachother. LiDOs livelihood is sales with large companies through a professional sales force. As a single developer who needs to decide between a persistence library and a nice holiday in the mediterranean, I will always go for Hibernate and the latter.
Christian -
LiDO Hibernate[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 14:46 EDT
- in response to Christian Sell
It is my perception, both from this thread and from other appearances, that LiDO is heavily relying on performance claims in their marketing.
Eric>>>>>>>This is true, indeed.
That alone has always made them incredible for me. The reasons for this have been well stated in this thread.
Eric>>>>>>>All O/R mapping products don't have the same performance. This is why customers are spending a lot of time in product evaluation. Performance is very often a key decision criterion. I'd like to add I regularly evaluate Hibernate, so I know what I'm speaking about.
> The way their CTO has involved himself in a rather unprofessional discussion on a thread dedicated to another product has not remedied that distrust.
Eric>>>Please note I didn't started that discussion about JDO in that thread. One satisfied Hibernate users asked for reasons to choose another product than Hibernate. I mentionned few arguments like standard compliance, performance, data source portability, tools...
Then LIBeLIS has been attacked (we would be out of the market because of Hibernate !, we are a "french" company, JDO is not a standard because no big names...).
>
> Having said that, I dont think Hibernate or LiDO/JDO are stealing anything from eachother. LiDOs livelihood is sales with large companies through a professional sales force. As a single developer who needs to decide between a persistence library and a nice holiday in the mediterranean, I will always go for Hibernate and the latter.
Eric>>>>I can certainly undertsand your point, and it reinforces what I said before. LiDO and Hibernate markets are different ones. They both offer different benefits to differents users, and that's nice, we don't have only one solution for all users. In some cases Hibernate is a good choice, sometimes LiDO is a better one, it mostly depends on the technical and economical constraints.
We can always discuss pros and cons of standards and OSS, but there is no need to spread low-level FUD against the competition and JDO in general. I prefer when Gavin propose a benchmark. Maybe it is not sufficient as someone stated, but it could help prospects in making a decision.
I don't know Gavin personaly, so I've no problem with him, but this is not the first time we had this kind of useless flame discussion. He must accept there is a competition and other products also have benefits.
I'll have the chance to meet him in JAOO in September and I hope it will allow to stop this bad relationship.
Keep cool, it's only technology :-)
Best Regards, Eric. -
LiDO Hibernate[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: June 10 2003 15:02 EDT
- in response to Eric Samson
Eric>>>Please note I didn't started that discussion about JDO in that thread. One satisfied Hibernate users asked for reasons to choose another product than Hibernate. I mentionned few arguments like standard compliance, performance, data source portability, tools...
Eric,
I think we are all a little tired of this bickering, but you can't take the high road now. No, you were not the first person to discuss JDO in this thread. However, your first post listed eight reasons to "use LiDO first instead of Hibernate". Four of these reasons were the *same* - "Performance". Obviously, the implication here is that LiDO is far superior to Hibernate when it comes to performance. Since you provided no evidence, I would call this FUD and Gavin had every right to be pissed.
You can't poke somebody in the eye and then say, "Let's not fight."
Ryan -
LiDO Hibernate[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 16:42 EDT
- in response to Ryan Breidenbach
Ryan, you
OK, so let's do that benchmark, and we'll see what happens based on FAcTS.
And maybe we will see who is spreading FUD.
To me, saying LIBeLIS is a "french" company, and JDO is not a standard is real FUD. But who knows, I may be wrong. The figures will speak for us.
Best Regards, Eric. -
LiDO Hibernate[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: June 10 2003 17:39 EDT
- in response to Eric Samson
To me, saying LIBeLIS is a "french" company, and JDO is not a standard is real FUD. But who knows, I may be wrong. The figures will speak for us.
>
> Best Regards, Eric.
Here is what Gavin said:
<quote>
For the information of other readers, Eric Samson is the president of LIBeLIS, "a privately held french company founded in 2000."
</quote>
Here is what your web site says:
<quote>
LIBeLIS is a privately held french company founded in 2000.
</quote>
I'm not quite sure why you consider Gavin's comments FUD.
Whatever.
Ryan -
FUD or not[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 11 2003 01:58 EDT
- in response to Ryan Breidenbach
Ryan
the exact quote was:
"For the information of other readers, Eric Samson is the president of LIBeLIS, "a privately held french company founded in 2000." He wants you to entrust your enterprise infrastructure to his product, while simultaneously induging in absurd claims like this."
The first sentence is a fact, based on public information. But the second one is saying: you cannot work with such a company.
As a summary of that thread I understand:
* Hibernate is the perfect product, nobody is allowed to say something else
* Hibernate shows ultimate performance in any case, forever, and nobody is allowed to say something different
* There is absolutely no need for any standard in persistence, Hibernate is here, they give you the source this is the best standard
* JDO is not a standard, Hibernate is the standard
* There is absolutely no need to access something else than an RDBMS
I now understand, all JDO vendors (>10 of them) plus organizations like JBoss, Apache/Jakarta/OJB, ObjectWeb, plus initiatives like TJDO, XORM, plus the JCP are all in the wrong way. No discussion is allowed.
Best Regards, Eric. -
FUD or not[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 11 2003 03:01 EDT
- in response to Eric Samson
As a summary of that thread I understand:
> * Hibernate is the perfect product, nobody is allowed to say something else
> * Hibernate shows ultimate performance in any case, forever, and nobody is allowed to say something different
> * There is absolutely no need for any standard in persistence, Hibernate is here, they give you the source this is the best standard
> * JDO is not a standard, Hibernate is the standard
> * There is absolutely no need to access something else than an RDBMS
>
> I now understand, all JDO vendors (>10 of them) plus organizations like JBoss, Apache/Jakarta/OJB, ObjectWeb, plus initiatives like TJDO, XORM, plus the JCP are all in the wrong way. No discussion is allowed.
Noone said any of this at any time. The past hast rather showed that JDO vendors tend to devalue everything else as inferior, and feel the urge to evangelize the naive crowd, in acts of inappropriate arrogance (BTW, spec authors sometimes do too, probably due to the same reasons). Eric, you should know best what I'm talking about, shouldn't you?
There is definitely value in both Hibernate and the JDO approach. The question is not about general viability but about rather subtle advantages and drawbacks. Marketing broadsides certainly don't help in this respect.
And finally, regarding your point on discussion allowed. Let's review your first contribution to the discussion on technical merits that you obviously wanted to initiate:
<eric>
few reasons to use LiDO first instead of Hibernate:
1. Performance
2. Respect a true standard
3. Performance
4. Data source portability
5. Performance
6. Tools (GUI mapping tool, business browser, ...)
7. Performance
8. Real transparent persistence
and much more.
</eric>
To my understanding, this isn't called discussion but marketing - blatant and provoking one, that is.
Juergen -
TV-shop[ Go to top ]
- Posted by: Wille Faler
- Posted on: June 11 2003 03:27 EDT
- in response to Juergen Hoeller
Regarding the Lido vs Hibernate discussion here: I really dont have a clue of which one is technically better, but personally I dont quite like the fact that a lot of people seem to use these forums to plug their own products and services.
It is in my opinion ok to mention them if you can carry an argument with that, but please dont turn these forums into a TV-shop for nurds with claims that "our product gives you excellent performance, buy it today and get a free ironing-board with it!".
That will only make a lot of people tune out, go to sleep or "switch the channel". -
Finished[ Go to top ]
- Posted by: Gavin King
- Posted on: June 11 2003 03:53 EDT
- in response to Wille Faler
I think we should dead the discussion. It just makes everyone look bad. There are many interesting technical issues here, and I am sorry the conversation turned acrimonious. Eric shouldn't have posted unsubstantiated stuff and I should have ignored him. But it takes passionate people to build great software - and passionate people tend to clash heads from time to time ;)
Version 2.0 is a huge step forward for our project and I'm very proud of the result. Again, thanks so much to everyone (way too many to list - you can see some of their names in the changelog) who contributed code, documentation, testing, web design and good ideas.
I'll post my thoughts about what should be on the version 2.1 roadmap to the mailing list sometime in the next week. No resting on laurels now!
Peace
:) -
Finished[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 11 2003 05:21 EDT
- in response to Gavin King
Hibernate boys,
I did find a sample on how to use the Criteria API and its very interesting. Does it support full HQL or just a subset ?
List cats = session.createCriteria(Cat.class)
.add( Expression.like("name", "Iz%") )
.add( Expression.gt( "weight", new Float(minWeight) ) )
.addOrder( Order.asc("age") )
.list(); -
Finished[ Go to top ]
- Posted by: Wille Faler
- Posted on: June 11 2003 06:24 EDT
- in response to Gavin King
Personally, I was glad to get the news about Hibernate since I havent used it before, and I am seriously thinking about having a sit-in this weekend to familiarize myself with it (I have no life, ok?!).
News (even if they are "products") are always welcome reading for me, but they have to have some merit besides being a "cut and paste job" from the marketting departments "customer benefit"-publication.
Things went a bit wrong when there started to be complete plugs and anti-plugs for libelis (or whatever the name was).
An interesting discussion of pros and cons for JDO vs Hibernate is interesting, a clichéd "customer benefit list" without arguments for some product that happens to be an implementation of JDO (barely mentioned) is completely uninteresting (hence the TV-shop metaphor).
Well thats my view, feel free to disagree with me. -
Finished[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 11 2003 06:46 EDT
- in response to Gavin King
I think we should dead the discussion.
Eric>>>>>>>I agree we should dead that bad discussion ... and continue the good one.
The good part of this thread was the proposal from D. Ezzio to try to define a common persistence layer benchmark.
I think it could interest most potential users.
Gavin raised an interesting point about the benchmark design: it should only test the database access layer, not the DB engine, or the App server, or the network itself.
Conversely, most users want to evaluate their database access layer in a realistic and complete environment.
It means we should design something that can be run alone or within a J2EE app server. It could be nice the benchmark is packaged with all the necessary instrumentation (JMeter, Ant, ...).
The benchmark could be used to test how performance evolves with number of users but it could also measure the memory usage and so on. It could also measure the number of LoC, and things like that.
Also, this benchmark should be portable to various persistence technologies like TopLink, Cocobase, Castor, JDO products, OMG products or other.
We should have soon a first version of the public Rubis benchmark ported to JDO. It allows to compare JDO products between them, and it also allows to compare JDO versus Entity Beans and JDO versus manual JDBC.
We could use that benchmark as a starting basis, if anyone agree, but this benchmark, has a limitation: the object model is not very complex (it has to be run with Entity Beans) so it does not really allow to evaluate how real complex object models are persisted.
Best Regards, Eric. -
Finished[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 11 2003 07:08 EDT
- in response to Eric Samson
Gavin raised an interesting point about the benchmark design: it should only test the database access layer, not the DB engine, or the App server, or the network itself.
> Conversely, most users want to evaluate their database access layer in a realistic and complete environment.
Each one, Hibernate or JDO, have their design constraints, and I think that can impact in different architectures, web, swing, etc.
For example, the architecture of an web application can have different impacts on Hibernate and JDO, but in a standalone swing application might not have different impacts. Am I right, or not ? -
Finished[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: June 11 2003 08:21 EDT
- in response to Eric Samson
No of benchmarks can say "Product A is better than B". if performance is the main criteria http://sourceforge.net/projects/prevayler will win this war.
If this benchmark will be for RDBMS frameworks only, product optimized for specific RDMS or specific use case will win this war.
It is possible to invent some formulas for Benchmark like:
1) transactions_per_second*(free ? 1 : 0 )
2) transactions_per_second*(standard ? 1 : 0)
Interesting Benchmark framework, is not it ?
Benchmark designed by author has no meaning, let independant consultants to do the job, but I am sure no of authors will agree with results, if they will not win.
I do not need this stuff, marketing needs it. -
TV-Shop[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 11 2003 06:59 EDT
- in response to Wille Faler
Maybe we could propose to setup a policy (I don't know whether or not it is technically feasible with the TSS infra-structure):
* products annoucement threads should be clearly identified
eg: Hibernate.org announces new Hibernate x.y
* When a thread is clearly identified as a product announcement from a vendor or organization, then other vendors or users of other vendors should not participate:
eg: nobody says: "we offer/ we use the same kind of product, but it is better, cheaper, ... please visit that site".
* When a thread is clearly identified as a product announcement from a vendor or organization, that vendor agrees not to bash competition
eg:
Q: Do you support JDO ?
A: No, because it sucks.
(correct answers would be: No, or Not Yet...)
Best Regards, -
TV-Shop[ Go to top ]
- Posted by: Wille Faler
- Posted on: June 11 2003 08:29 EDT
- in response to Eric Samson
How about just a policy of acceptance when it comes to marking non-argumentative "bashing" comments noisy? In other words: the people of this community set a standard were we accept noisy-marking of posts with the "I hate X it sucks, Buy my product instead, its great!"-type (with not a hint of an argument for why it sucks or why the other one is great).
I´m quite new to participating in these discussions, but I feel that these forums have a great possibility for people to educate eachother, share knowledge, discuss and argument, keep up-to-date on current events (yes, even products, despite my original post). Its just the obvious "marketing" in midst of a discussion i am not to fond of.
Do mention your product if you have a relevant argument attached to it, or rather attach the product as an example for the argument. But stear clear of statements such as "our product offers better performance [end of post]".
And with regards to actual selling: my experience is that companies and products that live on their own merits without bashing of competitors usually tend to get more trustworthyness.
I always think to myself when someone is bashing another product: "Why is he so intent on taking the focus of his product? Whats wrong with his product?". Its a bit of a negative tactic in my opinion.
A good discussion of pros and cons of different approaches is always good, but mere "bashing" is never productive, because it tends to take people to a childish level.
Oh well, hope someone understood the point I was trying to make. :) I have nothing against neither Hibernate or libelis, its just that I dont like bashing and I do think people are intelligent enough to recognize a shameless "off-topic" plug when they see one. -
thread conventions[ Go to top ]
- Posted by: Christian Sell
- Posted on: June 11 2003 10:21 EDT
- in response to Eric Samson
* products annoucement threads should be clearly identified
> eg: Hibernate.org announces new Hibernate x.y
I think the original title of the thread "Hibernate 2.0 Released" was as clear as it could have been (to anyone with a reasonable amount of common sense, that is).
> * When a thread is clearly identified as a product announcement from a vendor or organization, that vendor agrees not to bash competition
>
I suppose you will be the one to define what consitutes "bashing"? Maybe come up with a list of permissible vocabulary?
I think all we need is more people with a sense for dignity and mutual respect. Not stupid rules (sorry for that one).
regards,
Christian -
No Respect[ Go to top ]
- Posted by: alex chudnovsky
- Posted on: June 11 2003 03:25 EDT
- in response to Eric Samson
If you wanted to promote your product you should have done it in another thread.
It was absolutly unwarrented to post your comments about a product that you are personally involved in on a thread which was suppose to mark a celebration of hibernate in its new release.
You talk about not being allowed to say this or that. Nonsense, you can talk about it all you want, but pay due respect where you are talking about it.
Start your own thread and talk all that you want.
You make it sound like your a victim yet you were the one who added fire to the discussion by promoting your product and belittling hibernate. -
FUD or not[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: June 11 2003 04:59 EDT
- in response to Eric Samson
Some of us contribute for open source JDO implementations too and we are not enemies. Hibernate is not the best standard, I do not think the best standard exists for the all use cases (I use plain JDBC and UDF for my projects too). Persistence, performance tests and performance tuning are not trivial and
propoganda like "my standard stuff is x% faster than your no cost code" doe's not help for discussion too. -
a french company[ Go to top ]
- Posted by: Christian Sell
- Posted on: June 10 2003 18:02 EDT
- in response to Eric Samson
Funny. Since when is being called a french company an insult or FUD - in particular if you *are* a french company? Lets not carry that political stuff too far
as far as I am concerned, I like france. They have good food and wine, and I have even seen evidence that their software isnt that bad either. -
LiDO Hibernate[ Go to top ]
- Posted by: Chris Mathews
- Posted on: June 10 2003 17:20 EDT
- in response to Ryan Breidenbach
Four of these reasons were the *same* - "Performance". Obviously, the implication here is that LiDO is far superior to Hibernate when it comes to performance.
Really? I thought the implication was that he couldn't come up with more than five reasons and that even his five reasons were very questionable. I guess I just see things differently... ;) -
out of the market[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 10:12 EDT
- in response to Gavin King
The reason for this kind of behaviour is that LiDO is being squeezed dry in the marketplace by OSS projects like Hibernate and OJB and, if this behavior is any indication, will presumably go under.
Eric>>>>>>>>We are not squizzed dry at all.
OSS projects have benefits and drawbacks.
The key benefit is for users with no money.
We interest prospects when the "free" argument is not the only one.
==================
I guess you guys KNOW that we have more users than the JDO vendors put together and realize what that means for your bottom lines.
Eric>>>>>So what ?
An Hibernate user would have never been a LIBeLIS customer (as they have no money) so it does not change our bottom line at all.
====
>
> For the information of other readers, Eric Samson is the president of LIBeLIS, "a privately held french company founded in 2000." He wants you to entrust your enterprise infrastructure to his product, while simultaneously induging in absurd claims like this.
Eric>>>>>>Which company is more linked with a technology ?
The one using proprietary tools from Hibernate, or the one using an implementation of a standard ?
Best Regards, Eric. -
out of the market[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 10 2003 10:38 EDT
- in response to Eric Samson
Eric>>>>>>>>We are not squizzed dry at all.
> OSS projects have benefits and drawbacks.
> The key benefit is for users with no money.
> We interest prospects when the "free" argument is not the only one.
A far important key benefit is the transparency of the project itself, and the extremely high responsiveness for bug reports and change requests. And especially with frameworks and other lightweight middleware, the availability of the source code is worth a lot.
> I guess you guys KNOW that we have more users than the JDO vendors put together and realize what that means for your bottom lines.
>
> Eric>>>>>So what ?
> An Hibernate user would have never been a LIBeLIS customer (as they have no money) so it does not change our bottom line at all.
An open source project isn't just for people with "no money". Come on, this is a silly argument. Many development teams simply prefer open solutions for stuff that's so tightly integrated into their applications. An "open standard" is worth something, but an active "open product" may be worth even more.
What if you miss a feature in a standard spec? You might literally have to wait for years to get it, if you'll get it at all, or rely on vendor-specific extensions. Expert-group-driven specs tend to ignore user feedback somewhat, while open source projects can't live without it. The turnaround time for new features in open source projects can often be measured in weeks or even days. No implementation of a standard, or proprietary commercial product, can keep up with that.
> Eric>>>>>>Which company is more linked with a technology ?
> The one using proprietary tools from Hibernate, or the one using an implementation of a standard ?
This is debatable, IMHO. With a commercial implementation of an open standard one is still heavily tied to the vendor, at least for large projects. So people might decide to put their trust into popular open source projects because they know there isn't anything going on behind the scenes. Admittedly, the availability of commercial support can be important - but most popular open source products have commercial consultants around.
Juergen -
Blah blah blah[ Go to top ]
- Posted by: Ryan Breidenbach
- Posted on: June 10 2003 10:46 EDT
- in response to Eric Samson
Eric>>>>>So what ?
> An Hibernate user would have never been a LIBeLIS customer (as they have no money) so it does not change our bottom line at all.
I am using Hibernate in production right now. I would have never been a LIBeLIS customer, but not because it is commercial. First, I have never heard of it, so that pretty much ruled it out right there :-) That said, having my persistence framework adhere to a standard is not critical to me. I can isolate my persistence mechanism with good design and shield my application from any changes. What *is* critical is:
1. Flat learning curve (check)
2. Good support (check)
3. Transparent, as in I don't have to change my persistant objects (check)
4. Flexible (check - big time!)
5. Developer friendly (check - big time!)
6. Good documentation (check)
7. Active (check - from 1.0 to 2.0 < 1 year?)
Did you notice that free what not on this list? We use Oracle and WebSphere in production. They are obviously *not* free. Money was not the issue. Quality was, a Hibernate passed the test. Besides, there are other OSS O/R tools out there, like OJB and Castor. I have tried them all and IMO Hibernate blows them away.
On a side note - I love the fact that it is open source. I was playing with the SchemaExport tool last week. There was an Ant task that wraps the SchemaExport class, but the task does not expose all of the available properties. So guess what - I changed to code to what I needed and was up and running. OSS rocks!
> The one using proprietary tools from Hibernate, or the one using an implementation of a standard ?
As I said before, so what? Struts isn't a standard, but has become some what of a de facto "standard". Why? Because people got tired of waiting for Java Server Faces to become the standard (BTW - we are still waiting). I can see Hibernate becoming the de factor O/R mapper. Why? Because O/R mapping it what it does, and it does it very well. JDO may let me persist to an object database, file, etc. So what? I persist objects to a relational database. And guess what - *most* Java developers do this. It this scenario, Hibernate makes sense.
Ryan -
Did you really say that?[ Go to top ]
- Posted by: Dave Hewitt
- Posted on: June 10 2003 11:14 EDT
- in response to Eric Samson
Eric>>>>>So what ?
An Hibernate user would have never been a LIBeLIS customer (as they have no money) so it does not change our bottom line at all.
I cannot believe I've just read that. Costs for tools such as this are mostly a trivial concern, compared to developer costs and time-to-market pressures. The reason I (as a hibernate user) would not currently use LiDO is that,since it does not have all of the functionality necessary to support our applications, any time spent using it is wasted time. That is my bottom line. -
Hibernate is used by a Fortune 100 company that made over a bill[ Go to top ]
- Posted by: t g
- Posted on: June 10 2003 11:27 EDT
- in response to Eric Samson
An Hibernate user would have never been a LIBeLIS customer (as they have no money) so it does not change our bottom line at all.
Hibernate is used by a Fortune 100 company that made over a billion dollars in profit last year. -
Hibernate users[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 11:41 EDT
- in response to t g
I've never said Hibernate is not used by large companies.
I'm sure there are a lot of Hibernate users that are happy with the product. That's cool.
The same way I don't put any discredit on open source in general.
Hibernate is certainly a nice product, with a lot of features and an active community.
But it does NOT impact our business at all ! I cannot let someone saying this with no proof.
With any Java technologies you have both commercial and OSS products.
Both have pros and cons. JBoss is a good product, but there is a market for WebLogic / WebSphere.
A major benefit of OSS is the "free" aspect (it is what prospects said). Commercial products have different benefits.
Hibernate is good but it is not the only solution.
Believe me or not, a lot of customers are concerned by the standard question.
Best Regards, Eric. -
Hibernate user verses LIBeLIS customer[ Go to top ]
- Posted by: Jeff Boring
- Posted on: July 10 2003 14:59 EDT
- in response to Eric Samson
An Hibernate user would have never been a LIBeLIS customer (as they have no money) so it does not change our bottom line at all. <
I lead a team that choose Hibernate over LIBeLIS at AT&T Labs. BTW, these applications were then outsourced to IBM GS. I discussed this at lunch one day with a friend who works in the middleware group at PWC. They told me last week that they had decided to use Hibernate too.
AT&T Labs, IBM GS & PWC seem like lost LIBeLIS customer to me.
Jeff -
getting squeezed out of the market.[ Go to top ]
- Posted by: David Ezzio
- Posted on: June 10 2003 10:21 EDT
- in response to Gavin King
Quote: For the information of other readers, Eric Samson is the president of LIBeLIS, "a privately held french company founded in 2000." He wants you to entrust your enterprise infrastructure to his product....
Hi Gavin,
Actually the point of an API standard like JDO is that by buying Lido and using it, you are NOT entrusting your enterprise to the new French company that Eric founded. You wake up tomorrow and Lido is missing in action, you go to another solution with minimal porting issues. The biggest problem you have right now in such a port is the data schema. Eric is leading the charge on the expert committee to standardize the data schema. So perhaps that problem will be minimized with the next revision of the standard.
Anyway, I realize that we JDO guys have hijacked your thread celebrating your new release of Hibernate. My congratulations.
David Ezzio -
Why not use Hibernate in the first place then?[ Go to top ]
- Posted by: Michael Mattox
- Posted on: June 11 2003 03:09 EDT
- in response to Eric Samson
few reasons to use LiDO first instead of Hibernate:
And one reason not to: $4,000/CPU price tag. -
byte-code enhancement expense[ Go to top ]
- Posted by: Eric Samson
- Posted on: June 10 2003 08:46 EDT
- in response to Juergen Hoeller
Thus, JDO's dirty detection is more efficient, but comes at the expense of the need for modified objects.
Eric>>>Can you detail this expense please ?
Best Regards, Eric. -
byte-code enhancement expense[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: June 10 2003 09:34 EDT
- in response to Eric Samson
Thus, JDO's dirty detection is more efficient, but comes at the expense of the need for modified objects.
>
> Eric>>>Can you detail this expense please ?
See my arguments regarding decoupling and reassocation of objects with a new PersistenceManager above. At the root of the issue, I consider this caused by the PersistenceCapable-tied-to-its-PersistenceManager approach. A persistent object is somewhat dependent on its PersistenceManager: Most importantly, the object cannot keep its persistent (reassociation-capable) identity on its own, without its PersistenceManager being alive. -
Hibernate 2.0 Released[ Go to top ]
- Posted by: Herve Tchepannou
- Posted on: June 09 2003 15:57 EDT
- in response to Peter Monks
Congratulation to Hibernate team.
I've build one implementation of xpetstore with Hibernate-1.0, and I was just amazed on the simplicity and beauty of the framework. Im now completly sold to Hibernate.
I'm working on a contract right now and I made the decision to use Hibernate-2.0 and so far so good.
Kudo to Hibernate Team -
JDO instance in Two Tables[ Go to top ]
- Posted by: Robin Roos
- Posted on: June 09 2003 16:19 EDT
- in response to Herve Tchepannou
You could also just use one Customer class, enhanced to be persistence capable. This could be persisted through one PersistenceManager with one set of mappings, or through another PersistenceManager with different mappings.
Of course the application would ideally know which PM to use. When retrieving objects you could ask one PM first, and then ask the other, but there would be inefficiencies there.
Kind regards, Robin. -
Hibernate 2.0 Released[ Go to top ]
- Posted by: Haytham A
- Posted on: June 09 2003 17:53 EDT
- in response to Peter Monks
Does any one know where I can find the dtd for release 2.0 and where I can find some documetation about the meaning of the parameters in the mapping files? The Reference Documentation is pretty good but is does not fully cover the mapping parameters. -
Hibernate vs JDO vs CMP?[ Go to top ]
- Posted by: Wille Faler
- Posted on: June 09 2003 18:04 EDT
- in response to Peter Monks
Its probably on old old question, but since its a relevant one, I will ask it again:
Does anyone know of any really good comparison of all these technologies with regards to productiveness and benchmarks?
I have basically only used BMP and CMP thus far, and I am not overly impressed by CMP out of the fact that I feel it is more cumbersome to map complex situations and relationships with them, and in essence the EJB-QL to me feels like a cheap rip-off of plain SQL just to say that "hey, its not in the code, its in a descriptor". Hope that last part doesnt get me flamed for ignorance.. :)
As I mentioned, havent used Hibernate, but the "free as in beer" part always appeals to a nurd who wants to fiddle around at home as well without breaking eiter the law or the wallet.. -
Docs are good, an easy to read, organized book even better[ Go to top ]
- Posted by: t g
- Posted on: June 09 2003 19:27 EDT
- in response to Peter Monks
The docs are good but I'd rather have a book. I've got $50 dollars I'm itching to give away for a well written book on Hibernate. -
Docs are good, an easy to read, organized book even better[ Go to top ]
- Posted by: David Channon
- Posted on: June 09 2003 20:03 EDT
- in response to t g
Gavin is writing a book for Manning. Hold that $50.00 just a short time longer. -
Congratulation![ Go to top ]
- Posted by: Renat Zubairov
- Posted on: June 10 2003 01:01 EDT
- in response to Peter Monks
Congratulation Hibernate team!
I have used Hibernate for a while and I'm trully impressed it's functionality and design. Also design patterns on your site is very helpfull. Thank you!
I think you have created the best O/R-mapping tool especially for that price! -
The official announcement[ Go to top ]
- Posted by: Gavin King
- Posted on: June 10 2003 05:34 EDT
- in response to Peter Monks
I had intended to post this here as the official announcement of Hibernate2, before someone else beat me to it ;)
===================================================================================
The Hibernate project has released version 2.0 final, a stable build of the innovative Hibernate2 ORM solution.
Hibernate2 builds upon the stability and high performance of Hibernate 1.x, the most popular ORM solution for Java (and a finalist in the current JavaWorld Editors' Choice Awards). Hibernate2 adds more powerful querying capabilities via an elegant object-oriented query language - designed as a "minimal" extension to ANSI SQL.
Hibernate comes equipped with full documentation, examples, a brutal test suite, a rich set of development tools, and support by XDoclet, Middlegen and AndroMDA.
Hibernate emphasizes the following concepts:
* minimal model intrusion (Plain Old Java Objects)
* fine grained objects
* rich typing
* a powerful query language with full support for relational operations like
- inner, outer and full joins
- aggregation and grouping
- projection
- subqueries
* extreme scalability
Hibernate is Free Software (LGPL). The team is focussed upon building the best persistence solution for Java, keeping it free, and keeping it free of feature bloat and of the artefacts of DesignByCommittee. Development of new functionality is driven by the needs of actual users!
Website:
http://hibernate.sf.net
Full feature list:
http://hibernate.sf.net/4.html
User forum:
http://sourceforge.net/forum/forum.php?forum_id=128638
Download:
http://sourceforge.net/project/showfiles.php?group_id=40712 -
The official announcement[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 10 2003 05:55 EDT
- in response to Gavin King
Full feature list:
>
> http://hibernate.sf.net/4.html
>
The above link is not working. Here is a working link to the Full feature list:
http://hibernate.bluemars.net/4.html -
OJB?[ Go to top ]
- Posted by: Uladzimir Liapko
- Posted on: June 10 2003 07:49 EDT
- in response to Peter Monks
I have never used Hibernate, but used OJB quite heavily. Does anyone can compare both libraries? -
Hibernate 2.0 Released[ Go to top ]
- Posted by: Ray Harrison
- Posted on: June 10 2003 09:13 EDT
- in response to Peter Monks
We have a project that uses EMF from the Eclipse project to create an implementation of the Common Warehouse Metamodel. The CWM uses inheritance extensively and the model generates a couple of hundred classes. We are using Hibernate 2.0 to persist the implementation to SAP DB and it has been a true joy. I would absolutely recomend giving it a try.
Cheers
Ray -
EMF/CWM[ Go to top ]
- Posted by: Stefan Tilkov
- Posted on: June 11 2003 16:06 EDT
- in response to Ray Harrison
Ray:
I would be extremely interested to find out more about your experiences with this project. If you'd be willing to share some experience, please drop me an e-mail at stefan.tilkov(at)innoq.com. Thanks a lot!
Stefan -
Hibernate 2.0 Released[ Go to top ]
- Posted by: Erik Bengtson
- Posted on: June 11 2003 03:40 EDT
- in response to Peter Monks
This discussion started because I added my the numbers of own benchmark from JDO Libelis x Hibernate, which were not recognized by at least one side (Its sure its not a true benchmark).
Please, stop this discussion for a while and work together to create a recognized benchmark from both technologies. Isnt it better? -
Let's not forget a big "THANK YOU" to Gavin King[ Go to top ]
- Posted by: Henrik Klagges
- Posted on: June 12 2003 16:08 EDT
- in response to Peter Monks
Hello there,
among all this hibernate vs jdo discussion I'd like to add something important: Big THANKS MERCI GRAZIE DANKE TAK to Gavin to develop hibernate :-)!!
It's been a big present to us (and we use it in production with Oracle and mySql since January). Much better and easier to understand and quicker to work with than the other persistence mechanisms I know.
Cheers from Munich,
Henrik Klagges
TNGtech -
I have been reading this thread and...[ Go to top ]
- Posted by: Web Master
- Posted on: June 21 2003 23:14 EDT
- in response to Henrik Klagges
... I'm not sure if it's just me or is that Eric Samson guy from LiBELIS, or LiDO, or whatever the hell they are called, being a rude, arrogant French wanker, or what? I can assure you he has done nothing to create more support for his product, in fact quite the opposite. Eric, maybe you should hand over the marketing reigns to someone with a little PR experience. And humitlity.
Regards,
A keen observer. -
I have been reading this thread and...[ Go to top ]
- Posted by: shi yiying
- Posted on: June 24 2003 16:27 EDT
- in response to Web Master
We developed a project six months ago with LiDO, and just gave up it before really delivering it.Now we turn to Hibernate, programmers and cutomers are happy with it.
There are many reasons for that,just point some of them:
1.Using JDO , We just cannot do any complex query,statistic ,because JDO think every is object.JDO products result in very complex mapping structure which cannot be understand by "ordinary" programmer, so I don't know how can I count() or sum() something using very very complex and ungly SQL statement.But Query and Statistic is a very important type in business system.More,if you must use raw SQL statement for trivial statistic,database transparent is impossible(though very complex query must use raw SQL).Unfortunately, our program must run on SQL Server and Oracle simultaneity.
You know Hibernate can do this.
2.See JDO's spec---very simple mapping dtd with many "vendor extension". You cannot control mapping strategy.So we just cannot port our program from one JDO product to another.
You know we must use DAO layer.
3.JDO don't require you write detailed mapping xml files like Hibernate.Instead, To achieve transparency, JDO product normally create many small object in database.For example,In mature O/R framework like hibernate,you can control value object map to some column in Entity class table.But in JDO products,they will treat any object as Entity.
You know hibernate can do this.
4.Object span different PM instance?.....
----
So,if your program is correct forever and never envolve,that's ok.But if you get a bug, if you want change your schema and migrate your production data,you dive into database,every thing is horrible.
JDO mapping is simple,JDO programming is simple.But for real project, simple relation between classes is rare, maintaince is more costly.Full "Intelligent(or transparently)" is just a dream,a nightmare. -
I have been reading this thread and...[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: June 25 2003 04:19 EDT
- in response to shi yiying
I have never used JDO for production, but I do not believe it is possible to implement my applications as as nice set of objects with hidden database. Hibernate just more pragmatic than JDO and I agree with you, transparency is just a dream or a nice experiment.
I like experiments and it is a good way to innovate, but I do not think it is a good idea to sell experiment as standard. -
Object is the Root and Relational is the Leaf[ Go to top ]
- Posted by: Lu Yunhai
- Posted on: June 26 2003 00:49 EDT
- in response to Juozas Baliuka
Where does Relational Data Modle from?
At the past teen years without OO, Relational Modle is the efficient approach to store data. That's a transactional method.
Now, everything is Object. Object Modle is likely very closed to the real world. So the Object Modle is the original modle.
For old guys, they used to use Relational Modle.
For modern guys, they use Object Modle.
As Relational Modle is mature, we use RDBMS to store data, and we programming with Object Modle, that's ORM which follow in its position. -
Object is the Root and Relational is the Leaf[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: June 26 2003 06:51 EDT
- in response to Lu Yunhai
There are a lot of good ways for persistence and some of them are better for object persitence than RDMS.
Persistent data is just one of RDMS aspects and JDO is not a RDMS tool, it is a "Transparent Persistence Standard", hibernate is O/R mapping tool and it is more usefull if you need RDMS and you are not going to migrate to some persistent store like flat file (I do not think this kind of migration is realistic). -
I have been reading this thread and...[ Go to top ]
- Posted by: shi yiying
- Posted on: June 26 2003 02:41 EDT
- in response to Juozas Baliuka
JDO'spec should focus on O/R mapping starndard as well as unified api.
Many reports cannot be implements as objects. -
I have been reading this thread and...[ Go to top ]
- Posted by: Jerome Beau
- Posted on: July 08 2003 07:40 EDT
- in response to shi yiying
Hello,
Here are some comments.
> 1. Using JDO, We just cannot do any complex query...
Well the goal is to meet complex needs, not to generate or use something complex :) For example using JDO QL you can query without having to learn a new language (you just have to use Java semantics). Those queries are portable on all JDO implementations. You can query collections without having to juggle with "join" concepts (for example "someDepartement.contains(anEmployee) && anEmployee.manager == this", etc.). Actually I don't see which kind of "complex" queries Hibernate could run and a JDO implementation could not. But maybe you're talking about low-level/field-level queries. In that case just use plain SQL (most JDO vendors allow to do so).
> statistic,
That's an interesting feature, indeed. Does Hibernate support this ? Actually this is quite a high level one. Maybe some implementation (JDO or not) does or will support this.
> because JDO think every is object.
Actually every thing is an object in your application. But JDO implementations do not mandate that every object should be mapping into a table. That's just a matter of what you describe in your mapping (according to your implementation mapping capabilities).
> JDO products result in very complex mapping structure which cannot be understand by "ordinary" programmer,
Well if your mapping is really complex, I don't see how it could be described in a simple way, and I guess I would be as complex with any mapping engine. Futhermore, the way you describe your mapping is implementation-dependent with JDO, and you are free to choose the vendor that provides you the most simple and usable mapping description.
> so I don't know how can I count() or sum() something
Depending on your use case (if you intend to use your objects after counting them for example), it may make sense to use collection.size() or compute a sum in Java or not. If it doesn't and if you need low-level access, just use SQL to do so (both JDO and non-JDO vendors allow it).
> using very very complex and ungly SQL statement.
Once again it depends on the JDO implementation you choose. But usually the SQL query make sense to me. But counter-examples are welcome.
> But Query and Statistic is a very important type in business system.
Yes indeed.
> More, if you must use raw SQL statement for trivial statistic, database transparent is impossible (though very complex query must use raw SQL).
That's why both JDO vendors and non-JDO solutions often allow users to run plain-SQL queries.
>Unfortunately, our program must run on SQL Server and Oracle simultaneity.
So we agree on the need of datastore-independency.
> 2. See JDO's spec -- very simple mapping dtd with many "vendor extension". You cannot control mapping strategy.
As JDO is datastore-agnostic, it doesn't make sense to include mapping (i.e. relationship with datastore-specifics semantics) in the standard, which defines the interface level. However implementions do define such mapping languages.
> So we just cannot port our program from one JDO product to another.
Yes the point is that there is not JDO/RBDMS mapping language standardized yet, and I guess this would be a target for JDO 2.0, which would include a JDO/Relational specialized specification. Note that you cannot port your program from Hibernate to another solution in a better way.
> You know we must use DAO layer.
Yes to me DAOs still make sense with every solution (as you always want to abstract/hide persistence layer initialization/configuration, queries, optimizations, etc.), even if they get a lot simplified when using JDO, Hibernate, etc.
> 3. JDO don't require you write detailed mapping xml files like Hibernate.
JDO requires that you declare you persistent classes/fields in a XML file (JDO metadata) and doesn't impose a format for mapping information. JDO implementations may either use vendor tags or separate mapping files to do so.
> Instead, To achieve transparency, JDO product normally create many small object in database.
JDO only creates the objects you ask it to create, either small, big, embedded, etc. It depends on your mapping information and mapping capabilities of the JDO implementation you choose.
> For example, in mature O/R framework like hibernate, you can control value object map to some column in Entity class table. But in JDO products, they will treat any object as Entity.
What you describe is an embedded object (in RDBMS an object whose columns are concatenated with columns on another object). This is described in the JDO specification. Whether how it is supported (or not supported) is a matter of vendor implementation.
> 4.Object span different PM instance?.....
You're right, this is not possible today. You should have stated a use case where it is required.
> So, if your program is correct forever and never envolve, that's ok. But if you get a bug, if you want change your schema and migrate your production data, you dive into database, every thing is horrible.
If you want to change a schema, you have to either change your mapping or make your schema evolve. The former is required with any solution. The latter is provided by some vendors (don't know if schema evolution is supported by Hibernate).
> JDO mapping is simple, JDO programming is simple. But for real project, simple relation between classes is rare, maintaince is more costly. Full "Intelligent (or transparently)" is just a dream, a nightmare.
Well nothing is perfect, neither JDO or Hibernate. Maybe Hibernate will become JDO-compatible one day, who knows ? The fact is that both have meet happy customers.