Hibernate 2.0 Released

Discussions

News: Hibernate 2.0 Released

Bookmark and Share Get thread feed

  1. Hibernate 2.0 Released (132 messages)

    • Posted by: Peter Monks
    • Posted on: June 09 2003 01:54 EDT
    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
    Reply to this

    Threaded Messages (132)

  2. Hibernate 2.0 Released[ Go to top ]

    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.
    Reply to this Reply to original

  3. Hibernate 2.0 Released[ Go to top ]

    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.
    Reply to this Reply to original

  4. Hibernate MIddlegen plugin[ Go to top ]

    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
    Reply to this Reply to original

  5. Is Hibernate related to JDO?[ Go to top ]

    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.
    Reply to this Reply to original

  6. Is Hibernate related to JDO?[ Go to top ]

    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.
    Reply to this Reply to original

  7. JDO?[ Go to top ]

    Thanks for the response. How is Hibernate different from JDO?

    -Frank
    http://www.PushToTest.com
    TestMaker 4 is in beta
    Reply to this Reply to original

  8. JDO?[ Go to top ]

    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
    Reply to this Reply to original

  9. Thanks[ Go to top ]

    That helped alot. -Frank
    Reply to this Reply to original

  10. JDO?[ Go to top ]

    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
    Reply to this Reply to original

  11. Hibernate / JDO / CMP[ Go to top ]

    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?
    Reply to this Reply to original

  12. Hibernate / JDO / CMP[ Go to top ]

    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.
    Reply to this Reply to original

  13. Hibernate / JDO / CMP[ Go to top ]

    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.
    Reply to this Reply to original

  14. Hibernate / JDO / CMP[ Go to top ]

    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.
    Reply to this Reply to original

  15. Hibernate / JDO / CMP[ Go to top ]

    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.
    Reply to this Reply to original

  16. Dynamic Data Routing with JDX O/R Mapper[ Go to top ]

    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
    Reply to this Reply to original

  17. Hibernate / JDO / CMP[ Go to top ]

    <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
    Reply to this Reply to original

  18. Multiple table mapping[ Go to top ]

    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?
    Reply to this Reply to original

  19. Dynamic tables[ Go to top ]

    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.
    Reply to this Reply to original

  20. Dynamic table targets[ Go to top ]

    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.
    Reply to this Reply to original

  21. Dynamic table targets[ Go to top ]

    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.
    Reply to this Reply to original

  22. Use database table partitionning instead[ Go to top ]

    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 ...
    Reply to this Reply to original

  23. How Database Partionning Entry Relates To Hibernate[ Go to top ]

    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
    Reply to this Reply to original

  24. DBRouting in Persistence EdgeXtend[ Go to top ]

    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/
    Reply to this Reply to original

  25. JDO?[ Go to top ]

    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
    Reply to this Reply to original

  26. JDO?[ Go to top ]

    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.
    Reply to this Reply to original

  27. JDO?[ Go to top ]

    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
    Reply to this Reply to original

  28. JDO?[ Go to top ]

    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.
    Reply to this Reply to original

  29. JDO?[ Go to top ]

    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
    Reply to this Reply to original

  30. xPetStore[ Go to top ]

    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.
    Reply to this Reply to original

  31. xPetStore[ Go to top ]

    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
    Reply to this Reply to original

  32. xPetStore[ Go to top ]

    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 :-)))
    Reply to this Reply to original

  33. Don't believe this![ Go to top ]

    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!
    Reply to this Reply to original

  34. Don't believe this![ Go to top ]

    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
    Reply to this Reply to original

  35. umm[ Go to top ]

    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.
    Reply to this Reply to original

  36. JDO vs. Hibernate[ Go to top ]

    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
    Reply to this Reply to original

  37. JDO vs. Hibernate[ Go to top ]

    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
    Reply to this Reply to original

  38. yes, but[ Go to top ]

    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.
    Reply to this Reply to original

  39. JDO Optimistic Transactions[ Go to top ]


    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
    Reply to this Reply to original

  40. JDO Optimistic Transactions[ Go to top ]

    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
    Reply to this Reply to original

  41. JDO Optimistic Transactions[ Go to top ]

    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
    Reply to this Reply to original

  42. Hibernate with ODBMS[ Go to top ]

    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&currentLanguage=E

    yves yang
    Reply to this Reply to original

  43. JDO?[ Go to top ]

    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
    Reply to this Reply to original

  44. Fatal flaw or remediable blemish?[ Go to top ]

    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
    Reply to this Reply to original

  45. correction[ Go to top ]

    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.
    Reply to this Reply to original

  46. Hibernate Transparent?[ Go to top ]

    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
    Reply to this Reply to original

  47. CGLIB[ Go to top ]

    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 :)
    Reply to this Reply to original

  48. CGLIB[ Go to top ]

    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
    Reply to this Reply to original

  49. CGLIB[ Go to top ]

    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.
    Reply to this Reply to original

  50. correction[ Go to top ]

    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.
    Reply to this Reply to original

  51. correction[ Go to top ]

    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.
    Reply to this Reply to original

  52. correction[ Go to top ]

    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
    Reply to this Reply to original

  53. Fatal flaw or remediable blemish?[ Go to top ]

    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
    Reply to this Reply to original

  54. JDO Identity[ Go to top ]

    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
    Reply to this Reply to original

  55. Aha[ Go to top ]

    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....
    Reply to this Reply to original

  56. Aha[ Go to top ]

    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
    Reply to this Reply to original

  57. Aha[ Go to top ]

    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
    Reply to this Reply to original

  58. JDO Identity[ Go to top ]

    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.
    Reply to this Reply to original

  59. JDO Identity[ Go to top ]

    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
    Reply to this Reply to original

  60. JDO Identity[ Go to top ]

    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
    Reply to this Reply to original

  61. JDO Identity[ Go to top ]

    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.
    Reply to this Reply to original

  62. Why not use Hibernate in the first place then?[ Go to top ]

    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.
    Reply to this Reply to original

  63. getting squeezed out of the market.[ Go to top ]

    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_.
    Reply to this Reply to original

  64. out of the market ?[ Go to top ]

    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.
    Reply to this Reply to original

  65. Hibernate JDO benchmark[ Go to top ]

    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
    Reply to this Reply to original

  66. out of the market[ Go to top ]

    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,
    Reply to this Reply to original

  67. support from big names[ Go to top ]

    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,
    Reply to this Reply to original

  68. support from big names[ Go to top ]

    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
    Reply to this Reply to original

  69. support from big names[ Go to top ]

    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
    Reply to this Reply to original

  70. Hibernate a standard[ Go to top ]

    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,
    Reply to this Reply to original

  71. Hibernate a standard[ Go to top ]

    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!
    Reply to this Reply to original

  72. Hibernate a standard[ Go to top ]

    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.
    Reply to this Reply to original

  73. data source support[ Go to top ]

    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.
    Reply to this Reply to original

  74. data source support[ Go to top ]

    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.
    Reply to this Reply to original

  75. data source support[ Go to top ]

    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
    Reply to this Reply to original

  76. Let's roll the dice[ Go to top ]

    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
    Reply to this Reply to original

  77. suitably chastened[ Go to top ]

    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?
    Reply to this Reply to original

  78. Oh no, not another benchmark[ Go to top ]

    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
    Reply to this Reply to original

  79. Oh no, not another benchmark[ Go to top ]

    - 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.
    Reply to this Reply to original

  80. benchmarks[ Go to top ]

    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,
    Reply to this Reply to original

  81. Hibernate or LiDO[ Go to top ]

    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
    Reply to this Reply to original

  82. LiDO Hibernate[ Go to top ]

    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.
    Reply to this Reply to original

  83. LiDO Hibernate[ Go to top ]

    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
    Reply to this Reply to original

  84. LiDO Hibernate[ Go to top ]

    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.
    Reply to this Reply to original

  85. LiDO Hibernate[ Go to top ]

    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
    Reply to this Reply to original

  86. FUD or not[ Go to top ]

    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.
    Reply to this Reply to original

  87. FUD or not[ Go to top ]

    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
    Reply to this Reply to original

  88. TV-shop[ Go to top ]

    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".
    Reply to this Reply to original

  89. Finished[ Go to top ]

    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

    :)
    Reply to this Reply to original

  90. Finished[ Go to top ]

    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();
    Reply to this Reply to original

  91. Finished[ Go to top ]

    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.
    Reply to this Reply to original

  92. Finished[ Go to top ]

    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.
    Reply to this Reply to original

  93. Finished[ Go to top ]

    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 ?
    Reply to this Reply to original

  94. Finished[ Go to top ]

    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.
    Reply to this Reply to original

  95. TV-Shop[ Go to top ]

    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,
    Reply to this Reply to original

  96. TV-Shop[ Go to top ]

    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.
    Reply to this Reply to original

  97. thread conventions[ Go to top ]

    * 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
    Reply to this Reply to original

  98. No Respect[ Go to top ]

    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.
    Reply to this Reply to original

  99. FUD or not[ Go to top ]

    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.
    Reply to this Reply to original

  100. a french company[ Go to top ]

    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.
    Reply to this Reply to original

  101. LiDO Hibernate[ Go to top ]

    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... ;)
    Reply to this Reply to original

  102. out of the market[ Go to top ]

    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.
    Reply to this Reply to original

  103. out of the market[ Go to top ]

    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
    Reply to this Reply to original

  104. Blah blah blah[ Go to top ]

    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
    Reply to this Reply to original

  105. Did you really say that?[ Go to top ]

    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.
    Reply to this Reply to original

  106. Hibernate is used by a Fortune 100 company that made over a bill[ Go to top ]

    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.
    Reply to this Reply to original

  107. Hibernate users[ Go to top ]

    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.
    Reply to this Reply to original

  108. Hibernate user verses LIBeLIS customer[ Go to top ]

    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
    Reply to this Reply to original

  109. getting squeezed out of the market.[ Go to top ]

    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
    Reply to this Reply to original

  110. Why not use Hibernate in the first place then?[ Go to top ]

    few reasons to use LiDO first instead of Hibernate:


    And one reason not to: $4,000/CPU price tag.
    Reply to this Reply to original

  111. byte-code enhancement expense[ Go to top ]

    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.
    Reply to this Reply to original

  112. byte-code enhancement expense[ Go to top ]

    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.
    Reply to this Reply to original

  113. Hibernate 2.0 Released[ Go to top ]

    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
    Reply to this Reply to original

  114. JDO instance in Two Tables[ Go to top ]

    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.
    Reply to this Reply to original

  115. Hibernate 2.0 Released[ Go to top ]

    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.
    Reply to this Reply to original

  116. Hibernate vs JDO vs CMP?[ Go to top ]

    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..
    Reply to this Reply to original

  117. Docs are good, an easy to read, organized book even better[ Go to top ]

    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.
    Reply to this Reply to original

  118. Docs are good, an easy to read, organized book even better[ Go to top ]

    Gavin is writing a book for Manning. Hold that $50.00 just a short time longer.
    Reply to this Reply to original

  119. Congratulation![ Go to top ]

    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!
    Reply to this Reply to original

  120. The official announcement[ Go to top ]

    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
    Reply to this Reply to original

  121. The official announcement[ Go to top ]

    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
    Reply to this Reply to original

  122. OJB?[ Go to top ]

    I have never used Hibernate, but used OJB quite heavily. Does anyone can compare both libraries?
    Reply to this Reply to original

  123. Hibernate 2.0 Released[ Go to top ]

    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
    Reply to this Reply to original

  124. EMF/CWM[ Go to top ]

    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
    Reply to this Reply to original

  125. Hibernate 2.0 Released[ Go to top ]

    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?
    Reply to this Reply to original

  126. Let's not forget a big "THANK YOU" to Gavin King[ Go to top ]

    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
    Reply to this Reply to original

  127. I have been reading this thread and...[ Go to top ]

    ... 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.
    Reply to this Reply to original

  128. I have been reading this thread and...[ Go to top ]

    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.
    Reply to this Reply to original

  129. I have been reading this thread and...[ Go to top ]

    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.
    Reply to this Reply to original

  130. Object is the Root and Relational is the Leaf[ Go to top ]

    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.
    Reply to this Reply to original

  131. Object is the Root and Relational is the Leaf[ Go to top ]

    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).
    Reply to this Reply to original

  132. I have been reading this thread and...[ Go to top ]

    JDO'spec should focus on O/R mapping starndard as well as unified api.
    Many reports cannot be implements as objects.
    Reply to this Reply to original

  133. I have been reading this thread and...[ Go to top ]

    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.
    Reply to this Reply to original