Discussions

News: Featured Article: Comparing Hibernate with Cayenne

  1. Bill Dudney is writing Hibernate Live!, and he ran across our TheServerSide.com article on Cayenne. He decided to take it for a ride, and compare it to an example that he is using in his Hibernate world. Read on for his thoughts on the tools, APIs, and easy of use.

    Conclusion
    Overall in my limited experience Cayenne is a robust and fun framework to develop with. There are lots of cool features and if you know Hibernate its a small leap to grok Cayenne. Cayenne seems to have a vibrant community of users and the list was very friendly and answered my simpleton questions quickly and without trying to make me feel stupid. Cayenne seems to be a bit less mature than Hibernate in a few areas, for example, the distributed caching is new in version 1.1. In general though Cayenne is a great framework and I would definitely recommend that you take a look at it when you start your next project that requires an ORM framework.
    Read Bill Dudney in Cayenne And Hibernate

    Threaded Messages (92)

  2. What about advanced features[ Go to top ]

    Bill Dudney's class model used in comparison was pretty simple. It would be interesting to enhance it with advanced features as for example many-to-many associations or polymorphism.
  3. What about advanced features[ Go to top ]

    Cayenne seems to have a vibrant community of users and the list was very friendly and answered my simpleton questions quickly and without trying to make me feel stupid.
    That's why I left Hibernate. I asked questions and got grumpy answers back... they made me feel like a complete idiot. Also, the Hibernate documentation has a lot of flaws.

    In general, I find both Hibernate and Cayenne to be nice tools, but Cayenne is getting the edge and has much nicer community.
  4. What about advanced features[ Go to top ]

    Han: That's why I left Hibernate. I asked questions and got grumpy answers back... they made me feel like a complete idiot. Also, the Hibernate documentation has a lot of flaws.

    Sorry to hear that. Gavin was always very helpful to us. Also, the doc was one of the reasons why people liked Hibernate -- it was (is) pretty good doc from what I've heard.

    I've never used Cayenne .. were your experiences (coming from Hibernate) any different from the author of this article?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  5. Hibernate Community[ Go to top ]

    That's why I left Hibernate. I asked questions and got grumpy answers back... they made me feel like a complete idiot.
    Odd - one of the reasons I've always liked Hibernate is a strong community with relatively rapid, good support.
  6. What about advanced features[ Go to top ]

    Hi Han,

    I have found the Hibernate docs to be very good.

    Perhaps you caught someone on a bad day. The hibernate community is quite helpful. In some areas they probably are victims of their own success, too many questions not enough time. Sorry you had a bad time with the community but I don't think your experience is typical.

    Best of luck with Cayenne though!
  7. Free Support[ Go to top ]

    That's why I left Hibernate. I asked questions and got grumpy answers back... they made me feel like a complete idiot.
    I'm sorry you had this experience. I know I am sometimes too impatient - please realize that with hundreds of questions per day, every day, and the occasional very demanding user who refuses to read the docs and FAQ, it is actually really difficult to keep up with the traffic, and not get frustrated.

    We try to give everyone swift, correct answers, and we certainly value politeness. However, you should try to understand that some of us spend hours every day reading and answering posts in the user forum (and rejecting "bug" reports in JIRA), and this takes a definite toll on our lives. Try to imagine yourself in our position, I think you will understand.

    So, I guess, the problem is that free support is /by nature/ unscalable. It works nicely when you have 10 - 20 questions per day, but not so well when you have 100 - 1000.

    Remember, if this was commercial software, and you guys were paying customers, there would be a team of people doing first-level support. The disadvantage of using open source is that you might not get this team of patient people doing "handholding". The *advantage* is that the people answering questions are the ones who /actually wrote the software/.

    If you want to have your cake and eat it (get the advantage without the disadvantage), we offer commercial dev support, where you get the choice to pay for the luxury of "handholding". This level of choice is way beyond what any commercial vendor can provide.

    peace
  8. I got a rude treatment from some hibernate guys too today for just asking a question. Not only they did not answer my question, but also they deleted it.
    The only reason is in some of my replies I used a magic word "bug" in a sentence like "is it a bug". I guess your experience is not unique yet and I guarantee that kind of treatment will not be the last. He may think he is the God in Hibernate because somebody told him that. Then he forgets who he is for now. What a shame.
  9. Modeling tool for Sissies[ Go to top ]

    If GUI Modelers are for Sissies then why was MiddleGen done at all?

    Has anyone looked at:

    http://www.devaki.org/screenshot.html

    This works with Apache Torque and shows how a modeling environment can add better visualization and enhance productivity.

    Gavin: Please wake up. Not everyone thinks the same way. Pictures are worth ...
  10. How about comparing to TOPLink?[ Go to top ]

    Bill, have you considered comparing Hibernate / Cayenne to Oracle's TOPLink. I'd certainly be interested in your comments.
  11. Hi Tim,

    I've used TopLink before and I really liked it but its been so long that I will have to start from scratch. That is a great idea though, watch my blog and I'll try to get to it in the next few weeks.

    Thanks for your interest!

    TTFN -bd-
  12. The Cayenne API is about as easy to use as the Hibernate API
    In Hibernate the persistence is purely orthogonal to the objects and you can persist any POJO that you can map - In Cayenne the objects that are persisted know they are persistent
    in Hibernate optionally, a persistent class might implement the interface Lifecycle
    Cayenne seems to be a bit less mature than Hibernate in a few areas
    Well, I do not see any reasons why I should be interested in Cayenne....

    But the comparison is great, thank you Bill! It shows IMO that Cayenne is yet another unnecessary framework and wasted efforts.
  13. Well, I do not see any reasons why I should be interested in Cayenne...
    Umm... GUI Modeler... Ease of use...
    But the comparison is great, thank you Bill! It shows IMO that Cayenne is yet another unnecessary framework and wasted efforts.
    Yeah! So is Mac OS X and Linux :-)
  14. Seriously though, in 2001 when we started Cayenne there was nothing like that in the open source (and considering the whole package, Cayenne is still very unique). Of course there were commercial products - TOPLink, CocoBase, EOF.

    Well, these days open source development is a popularity contest. There is nothing wrong with it, I guess. But to come out on top you need to clearly realize this fact and then possess a certain set of non-technical skills. We were probably too idealistic thinking that there is no top or bottom, and we are just having fun. Isn't it what open source is all about ? ;-)
  15. I am getting a bit annoyed with people that say a particular framework is a "waste of time and effort". If you think that there is a current framework that does everything you need, fine. But maybe people aren't fully satisfied with others ways of doing things. Many advocates of Hibernate, Velocity, Spring, etc on this forum are quick to deride other possible solutions to problems that we face every day.

    Congratulations on a good article that seems to be a fair assessment of two very useful O/R tools.
  16. GUI Modeller for Hibernate[ Go to top ]

    I'd wish there would be GUI Modeller for Hibernate.
    Current Middlegen solution is not user friendly, hard to setup. Requires many manual steps like editing several config files. etc.

    Ideally i would like to see something like Middlegen + HibernIDE + easy setup.
  17. GUI Modeller for Hibernate[ Go to top ]

    Middlegen only requires the JDBC driver to be setup correctly and you off and working. I'm happy to listen to your suggestions for your improvements. Middlegen 2.1 has already started including GUI improvements with many more planned. Your suggestions will help guide the future. email: david@hibernate.org
  18. re: another unnecessary framework and wasted efforts - Not me! I'm glad to have some (open source) choices for O/R Mapping tools. Maybe I'm showing my inexperience w/ the Cayenne here but, I sure like the idea of an GUI tool rather than digging into hundreds of XML files.
  19. Well, I do not see any reasons why I should be interested in Cayenne....But the comparison is great, thank you Bill! It shows IMO that Cayenne is yet another unnecessary framework and wasted efforts.
    Agree only if you already know hibernate, but...

    I already have DB model (not quite big, ~15 tables). I started Cayenne Modeler and in <15 min I already had all persistance logic that works, and started working on business model.

    With hibernate it took me all afternoon to fight with its xml or xdoclet tags before I gave up.
  20. Is it just me, or do people only use Hibernate for simple object models?

    I've tried using it on a moderately complex object model, and I've had bad experiences with Hibernate. Very frequently, if you are doing anything complex, Hibernate can't handle the mapping and you have to modify your code to support Hibernate's "style". Even look at the Wiki page on the Hibernate docs, most of the answers to people's problems are along the lines of: change your code, create a custom user type, etc. Thus, I don't think I'm the only person who's experienced this annoyance.

    There are also other small things that don't seem like a problem until you have a larger system. For example, property-level lazy loading isn't even supported. Also, I don't find the community very supportive, people may answer simple questions, but anything more difficult often goes unanswered.

    Having done a project with Solarmetric's Kodo JDO product before, that was a much better experience. The hardest part was making sure your build process performed the bytecode manipulation in the proper order for a full project build. However, everything beyond that was almost 100% transparent.

    I used a pretty standard session EJB service layer architecture on both projects.

    I really wanted to give Hibernate a chance, but unfortunately it's been the technology to be most inflexible with certain designs. That's annoyed me enough to look elsewhere for persistence solutions in the near term. I'm really excited for JDO 2.0 though.

    Does anyone have any experiences of a moderate to high complexity object model being used with Hibernate? It seems fine for simple structures, especially where your data model is almost exactly the same in your object model as your schema, and when you are using more concrete classes rather than persistence. However, I'd like to see if I just don't have enough experience with it.
  21. and when you are using more concrete classes rather than interfaces
    typo, meant to say concrete class structure and dependencies, vs. abstract
  22. Hi Steven,
    I/we use Hibernate on complex applications wo being frustrated. Usually, it makes me think of a better application/DB. Every single time I was in pain, it was because of a badly designed legacy DB which did not respect Relational model.
    User Type is not a "workaround", it is a feature we are pretty proud of, it really allows good domain models wo ORM link and is good at abstracting a bit more DB from java code.
    Property-level lazy loading is not supported and it is intentional. We consider it not to be a good feature, please see why on the Hibernate wiki area or in the user forum. It is way more a marketing feature than a optimization feature.
    As Gavin said, we don't really have time to deeply answer complex questions, this is a free support, remember.

    Emmanuel
  23. Emmanuel: Every single time I was in pain, it was because of a badly designed legacy DB which did not respect Relational model. [..] Property-level lazy loading is not supported and it is intentional. We consider it not to be a good feature ..

    The point is that what Hibernate does, it does pretty well. If someone needs strong support for some of the features that Hibernate doesn't have (purposeful or otherwise,) there are other solutions available, open source and commercial, relational and non, lazy-property-loading and agressive up-front, mapping to single table or multiple, supporting SQL aggregates or not .. and as long as the number of general-purpose options in the market is small enough to keep track of, it works well.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  24. features[ Go to top ]

    Emmanuel: Every single time I was in pain, it was because of a badly designed legacy DB which did not respect Relational model. [..] Property-level lazy loading is not supported and it is intentional. We consider it not to be a good feature ..The point is that what Hibernate does, it does pretty well. If someone needs strong support for some of the features that Hibernate doesn't have (purposeful or otherwise,) there are other solutions available, open source and commercial, relational and non, lazy-property-loading and agressive up-front, mapping to single table or multiple, supporting SQL aggregates or not .. and as long as the number of general-purpose options in the market is small enough to keep track of, it works well.Peace,Cameron Purdy
    Cameron, I completely disagree with you here. We are trying to provide a tool with /no/ tradeoffs. Hibernate should be the best solution for /any/ project which needs an ORM solution. (OTOH, ORM is not suitable ever project, and never will be.) If people find they need to go to some other solution to get some feature, I want to know about that, because probably I need to implement that feature in Hibernate! I am not aware that this is very common, however, as evidenced by our "market" share....
  25. Well, I do not see any reasons why I should be interested in Cayenne... It shows IMO that Cayenne is yet another unnecessary framework and wasted efforts.
    You are so wrong.
  26. Well, I do not see any reasons why I should be interested in Cayenne....But the comparison is great, thank you Bill! It shows IMO that Cayenne is yet another unnecessary framework and wasted efforts.
    I spent hours and hours and hours trying to get Hibernate to work with a legacy schema I'm supporting. I poured through all the XML documentation I could find for Hibernate trying to figure out the proper mappings (yes, I RTFM). Eventually Ilearned that Hibernate does not support our schema's primary keys (they are binary -- arrays of bytes). I wasted a lot of time on this.

    Then I tried Cayenne. I was up and running in very short order. This was mainly due to the fact that the GUI Modeler didn't suck (it could use a few more features, but is pretty usable as-is and I *DID NOT* have to learn the XML mapping format) and it supported our binary primary keys. I did have a problem doing joins between tables with our funky keys, though. I asked the Cayenne list if anyone else had similar problems. Andrus replied *and produced a patch* very quickly (same day). People on the list have been very polite and helpful (so far).

    The fact that Cayenne works very much like EOF+EOGenerator is also a feature to me. I can generate my model classes easily (and customize the template) and never have to write POJOs/etc. I love working with a DataContext (similar to EOEditingContext) instead of the much more manual processes I've seen elsewhere (to me, this feature cannot be overstated). Cayenne is also under active development with some nice new features being added for 1.1 (validation, local/distributed caching, inheritance, more natural expression/query expressions, and more).

    For me, I don't see any reason why I should be interested in Hibernate. It is just another unnecessary framework and wasted effort. :-)

    On a more serious note, if Hibernate works for you and you are happy with it, that's great. I'm glad there are choices, though. For me, Cayenne is a much better fit (especially since it supports our schema) and is a great and promising ORM framework with ever improving tools.
  27. binary pks[ Go to top ]

    Actually, it is quite possible to use a byte array as a primary key in Hibernate. You should have enquired about this problem in the user forum.
    eg:

    <class name="MyClass">
        <composite-id class="ByteId">
            <property name="bytes" type="binary"/>
        </composite-id>
        ....
    </class>

    Another approach would be to use a UserType.

    Notice that I did not need to patch Hibernate to support this ;->


    (A byte array primary key is an extremely questional data model, by the way.)
  28. binary pks[ Go to top ]

    Questionable or not, if someone brought it up, then it probably exists in the real world. Most projects do not select their ORM tool first, and then design their business logic and data model around it. Only toy, throwaway, or tutorial code can afford that luxury.

    I don't care how much a Serious Financial Institution paid for you simple program. They'll probably pay it again next year (to yourself or someone else) for another implementation of read/writing to a file and arithmatic.
  29. binary pks[ Go to top ]

    Gavin: (A byte array primary key is an extremely questional data model, by the way.)

    Java should have a "Binary" type, just like it has "String" for char[].

    We have one (based on String) that has proven to be invaluable.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  30. binary pks[ Go to top ]

    Actually, it is quite possible to use a byte array as a primary key in Hibernate. You should have enquired about this problem in the user forum. eg:<class name="MyClass"> <composite-id class="ByteId"> <property name="bytes" type="binary"/> </composite-id> ....</class>Another approach would be to use a UserType.Notice that I did not need to patch Hibernate to support this ;->
    When I first looked at Hibernate, I distinctly recall reading in the documentation that a byte[] data type was not supported for primary keys (something about hashing, I believe). Perhaps this has changed since I first looked at it.

    Cayenne didn't have a problem with this. There was a slight issue doing joins, but that was fixed quickly.
    (A byte array primary key is an extremely questional data model, by the way.)
    I didn't design it. I only maintain it.
  31. byte[][ Go to top ]

    Correct, a primary key property of type byte[] is not supported, since Java arrays do not implement equals()/hashCode() correctly. That's why you need to wrap the byte array in a primary key class that does implement equals()/hashCode(). This has been possible since very, very early versions of HB. As I said, you should have asked in the user forum. No problem, you are happy with Cayenne now, so apparently it fits your needs.
  32. in memory persistence options ?[ Go to top ]

    Sort of off topic, but I'm very curious about in memory persistence engines (ie: prevayler.org ) but not having a proper query engine sucks.. is it possible to get Hibernate or Cayenne to operate in RAM ?
  33. in memory persistence options ?[ Go to top ]

    hsqldb can operate entirely in memory afaik, so you could just use hibernate with that
  34. I think the "problem" (not really a problem per se) with Prevayler-type approaches is that they use a fundamentally different mechanism for concurrency control. Most persistence mechanisms (whether it be relational or not) allow multiple transactions to be executed concurrently against the data model, and any conflicts get resolved via a granular locking mechanism of some sort.

    Prevayler-type approaches OTOH work by explicitly serialising all transactions that execute against the data model (conceptually at least - some more sophisticated implementations presumably allow concurrent read transactions and only make write operations exclusive). <aside>This isn't necessarily a problem mind you, since Prevayler transactions typically execute many orders of magnitude faster than typical database-backed transactions, so the loss of concurrency is more than made up for by the decrease in transaction duration.</aside>

    The conclusion I've come to is that these two approaches are semantically quite different - one allows for concurrent transactions "inside" your data model (with expensive locking mechanism to protect against conflicts) while the other solves the conflict problem by disabling concurrency altogether (with the associated performance benefit of not requiring those expensive locking mechanisms).

    My current thinking (which is by no means conclusive!) is that this semantic difference can't be abstracted away - each approach has to be used in a fundamentally different way. To bring this reply somewhat back on topic, this means that Prevayler-type approaches cannot really be compared directly to relational approaches (even if those relational databases are implemented in-memory and/or in-process).

    Of course this is all just theoretical blathering on my part - I haven't actually attempted to create an abstract persistence layer that can use either a "traditional" persistence mechanism (ie. a relational database) or an object-prevalence persistence mechanism (ie. Prevayler). I'd love to hear if anyone has attempted this - perhaps implementing each transactions in the relational database as stored procedures would bring the two models closer, semantically?
  35. EOF, now there was a tool[ Go to top ]

    I have to agree with the author that those that had the fortune of using EOF will sometimes look at the JDO vs Hibernate vs Cayenne vs iBatis vs JDBC vs Toplink vs Entity Beans (2.1) vs EJB Pojo persistence discussions with somewhat of an amused smile.

    No, I am not trying to spark 'that thread' off again here, rather to share the fact that a tool developed in the 90's (and deployed across multiple platforms) provided much of the power and sophistication that we are only now getting back to.

    I remember, with some horror, switching from an Objective-C/Java EOF world, to an EJB world. I could not believe the number of things I could no longer do.

    Anyway, to the authors of all of the persistence frameworks and standards, spare a thought for an elderly relative! For anyone who has time on their hands I would suggest http://developer.apple.com/documentation/WebObjects/Enterprise_Objects/index.html as a starting point. (No, I am not suggesting that the technology is a viable alternative, just a comparison to what is here today)
  36. RE: EOF, now there was a tool[ Go to top ]

    Hi Matt,

    EOF was very nice indeed but part of what made it cool was the untyped smalltalk flavor of Obj-C.

    You can't swizzle the isa pointer in Java :-)

    Hibernate seems to come fairly close to EOF probably about as near as one can get with Java.
  37. RE: EOF, now there was a tool[ Go to top ]

    Cayenne comes close to EOF is what I meant to type....
  38. RE: EOF, now there was a tool[ Go to top ]

    i think the closest think to EOF in Java ... is *** EOF in Java ***.
    what am i missing - ?
  39. Indeed, "Chubby"! ;-) Now, there's a good question... why HASN'T EOF taken off more as an ORM solution, given that it's still quite a ways ahead of the curve in many respects. It's also now perfectly reasonable to use WebObjects/EOF as a persistence solution within a 100% pure Java environment, and the XML support is getting quite solid. The arguments about it not being EJB-compliant don't seem as important anymore. Does it all really come down to marketing, or are there some technical barriers here I'm just not seeing?
  40. An advantage for Cayenne?[ Go to top ]

    Bill,

    In one of your blog entries:
    http://bill.dudney.net/roller/page/bill/20040521#testing_hibernate_mappings_with_dbunit

    you say:
    'My main testing goal was to make sure the Hibernate mapping files are correct, since that has been a major pain in the neck for me in the past. (For example, as I update the XDoclet tags I'll get something wrong but without a good test suite I did not notice until much later and had forgotten about the XDoclet tag I changed, thus I'll spend a lot of time running down rat trails).'

    Does this perhaps indicate an advantage for Cayenne? After all, with Cayenne you model both your Database Schema and your Persisent Classes in the GUI modelling tool, hit create, and voila. No worries about things getting out of sync, and no need to test with DBUnit. What do you think?

    James
  41. RE: An advantage for Cayenne?[ Go to top ]

    Hi James,

    Well I think you might still want to test your mappings. You are probably much less likely to face issues with Cayenne than with Hibernate because of the mapping tool. The tool validates the model on save as well as allowing you to validate the model when ever you want (very cool feature BTW). On the other had as you evolve your model it is still possible for the model to be internally consistent but have an issue with the database, esp if dba's are changing the db underneath you.

    Test everything, even the stuff you think won't break :-)
  42. RE: An advantage for Cayenne?[ Go to top ]

    You are probably much less likely to face issues with Cayenne than with Hibernate because of the mapping tool. The tool validates the model on save as well as allowing you to validate the model when ever you want (very cool feature BTW).
    On the other had as you evolve your model it is still possible for the model to be internally consistent but have an issue with the database, esp if dba's are changing the db underneath you.
    That's a good point! This is something I'll be adding to CayenneModeler - compare the mapping with current DB schema, report the changes, allow to merge them. I've been toying with various schema synchronization and merge approaches for a while, but doing for the purpose of validation is a fresh angle. Thanks for the idea :-)
  43. Complex datamodel with hibernate[ Go to top ]

    im working on aproduction system, leading porting effort from existing DAO pattern , to hibernate...it pretty complex.. and i found hibernate perfect O/R mapping, ive worked with EJB's(Entitybeans) as well..

    Middlegen/hibernate/xdoclet should be the de-facto standard, it simply looked at all of our tables(in sybase) and generated the .hbm files with xdoclet tags. then xdoclet again for java to .hbm....and reverse when needed completing the 'round trip'.. i bet the proces of generating the .hbm files caused u to make that assumption.. middlegen works great out of the box added with xdoclet

    Pharaoh
  44. 'My main testing goal was to make sure the Hibernate mapping files are correct, since that has been a major pain in the neck for me in the past. (For example, as I update the XDoclet tags I'll get something wrong but without a good test suite I did not notice until much later and had forgotten about the XDoclet tag I changed, thus I'll spend a lot of time running down rat trails).'

    Hibernate synchronizer a plugin for eclipse has been great for avoiding this pain and automating it for us....
  45. Hi Sam,

    Thanks I'll have to check it out!
  46. Featuresets[ Go to top ]

    Hum, actually the features I am aware of that other products have, that we don't have in 2.1 are:

    (1) lazy property-level fetching
    (2) single-class to multiple table mappings
    (3) GUI mapping tool

    Since, unlike most competing products, we have always supported projection in the query language, we have never needed (1), indeed, we believe it is a misfeature. However, since it is a marketing/FUD feature, we will support it in Hibernate3, most likely.

    (2) is likewise a misfeature, good object modelling practice is to use very fine-grained classes. If you have more database tables than classes, something is very wrong. However, it is a marketing feature and lots of commercial vendors use it to FUD us, so I already implemented this in Hibernate3, it works nicely (I would never use the feature /myself/, but....)

    (3) is for sissies ;-) Seriously, GUIs help new users, but slow down experienced users. We have a suite of tools that make life easier for /experienced/ users, quite the opposite to most vendors. Anyway, since the future is probably JSR-175 annotations, these GUI tools will probably die...

    Not aware of anything else we can't do. If someone wants to suggest something else they think we are missing, I'll respond here, I'm very interested to know ...

    Apologies to the Cayenne guys, I didn't want to hijack your thread. :-(

    P.S. I don't see how "use a UserType" is asking you to change your object model! Quite the contrary, UserTypes let you keep your object model unchanged, while enhancing the behaviour of Hibernate. Perhaps you misunderstood, and thought that the UserType interface is meant to be implemented by the domain model classes. A few new users make this mistake.
  47. GUI or not....[ Go to top ]

    (3) is for sissies ;-) Seriously, GUIs help new users, but slow down experienced users. We have a suite of tools that make life easier for /experienced/ users, quite the opposite to most vendors. Anyway, since the future is probably JSR-175 annotations, these GUI tools will probably die..
    This is what always surprised me when reading Hibernate site in the past. I thought a stance against GUI tools was some sort of internal joke that I don't understand :-) Looks like this is serious.

    But "GUI tools will probably die"... that's an interesting thought... Reminds me of a few friends of mine who use vi exclusively on large-scale Java projects, probably thinking that Eclipse is for sissies :-)

    Andrus
  48. GUIs[ Go to top ]

    I guess that the point is that I believe that Eclipse should be the /only/ tool you should need. As soon as I leave the Eclipse environment, I am wasting time. Now, nice built in support for editing XML or 175 annotations /inside/ Eclipse would be great, but these features are not specific to persistence.
  49. GUIs[ Go to top ]

    I guess that the point is that I believe that Eclipse should be the /only/ tool you should need. As soon as I leave the Eclipse environment, I am wasting time.
    There are many people who have different beliefs ;-)

    Actually at some point we thought of (re)writing CayenneModeler as Eclipse plugin, but then the consensus was that (a) all Java developers have JRE and Swing; (b) not all Java developers use Eclipse. So we stayed with Swing.

    BTW, it is very easy to configure Eclipse to open a mapping project in CayenneModeler when cayenne.xml is clicked.
  50. One class - multitable mapping[ Go to top ]

    (2) single-class to multiple table mappings

    Hi

    I don't mean to complain, but often you are not in control of your database schema. I'm currently working on a projects with a legacy schema that I can't change with some very, very bad database design in it...

    I want to map one class to multiple tables... What we have done now, to work around it, is to map 2 classes to two tables and make the one a joined-subclass of the other and to always use the joined subclass in the code...

    M
  51. One class - multitable mapping[ Go to top ]

    Is that for read or read and update?

    If for update how does it work - because you are obviously missing some columns.

    Jonathan
  52. One class to multiple tables...[ Go to top ]

    Sorry, I don't see your point?

    It shouldn't matter if it is for read or update... The sub-class has access to the superclasses fields and there is only ever one java instance for the two...
  53. Featuresets[ Go to top ]

    Since, unlike most competing products, we have always supported projection in the query language, we have never needed (1), indeed, we believe it is a misfeature. However, since it is a marketing/FUD feature, we will support it in Hibernate3, most likely.
    What about lazy loading of BLOB images, can this be solved by projection? (I am not familiar with Hibernate - my mistake - and do not know what projection is)
    (3) is for sissies ;-) Seriously, GUIs help new users, but slow down experienced users. We have a suite of tools that make life easier for /experienced/ users, quite the opposite to most vendors. Anyway, since the future is probably JSR-175 annotations, these GUI tools will probably die...
    I cannot agree with this. Although I agree that bad GUI can slow down experienced developers and misslead novice developers, nothing can beat realy good GUI. If GUI is good enough it can always beat text based tools in productivity. The other story is that building a good enough GUI is very hard and there are not many good GUIs out on the market. Not that building a goog GUI is that hard technically, but finding what GUI should provide and finding a way how the GUI should behave to ease the development for novice as well as for experienced developers is very, very hard.

    I also believe that providing 'two-way-tools' (GUI and text based) that can be interchanged in any stage of development quickly (like choosing another tab in tab control) is the best of both worlds.
  54. Lazy[ Go to top ]

    What about lazy loading of BLOB images, can this be solved by projection? (I am not familiar with Hibernate - my mistake - and do not know what projection is)
    Projection is the ability to specify exactly which properties should be retrieved from the database. In Hibernate, projection is a feature of the query language. In some other solutions, it is a metadata-level construct, where you use a named "use case" to select a particular fetch profile for the transaction. I never liked this approach, the metadata starts to get complicated that way. If we are going to specify projections somewhere, I prefer to specify it in the query (this is a matter of taste, I suppose).

    The use of lazy property loading makes your code much more vulnerable to n+1 SELECTs problems, so it is usually better to avoid this "feature". Basically, sequential SELECT is something we always try to avoid in ORM, it is never an efficient way to access relational data.

    Now, in reference to your particular use case, I'd better point out that in Hibernate, properties of type Clob or Blob may be declared as type java.sql.Clob, or java.sql.Blob, which allows the data to be retrieved by streaming (this is even "lazier" than lazy fetching by sequential SELECT).
    I cannot agree with this. Although I agree that bad GUI can slow down experienced developers and misslead novice developers, nothing can beat realy good GUI.
    I've never seen a good, efficient GUI for O/R mapping. I'll apply Occam's razor....
  55. Lazy[ Go to top ]

    What about lazy loading of BLOB images, can this be solved by projection? (I am not familiar with Hibernate - my mistake - and do not know what projection is)
    Projection is the ability to specify exactly which properties should be retrieved from the database. In Hibernate, projection is a feature of the query language. In some other solutions, it is a metadata-level construct, where you use a named "use case" to select a particular fetch profile for the transaction. I never liked this approach, the metadata starts to get complicated that way. If we are going to specify projections somewhere, I prefer to specify it in the query (this is a matter of taste, I suppose).The use of lazy property loading makes your code much more vulnerable to n+1 SELECTs problems, so it is usually better to avoid this "feature". Basically, sequential SELECT is something we always try to avoid in ORM, it is never an efficient way to access relational data.Now, in reference to your particular use case, I'd better point out that in Hibernate, properties of type Clob or Blob may be declared as type java.sql.Clob, or java.sql.Blob, which allows the data to be retrieved by streaming (this is even "lazier" than lazy fetching by sequential SELECT).
    I cannot agree with this. Although I agree that bad GUI can slow down experienced developers and misslead novice developers, nothing can beat realy good GUI.
    I've never seen a good, efficient GUI for O/R mapping. I'll apply Occam's razor....
    Actually, while I've generally been very happy using Hibernate, the lack of lazy loading for at least LOB properties has definitely been one of my pain points. Sure, the field can be defined as BLOB/CLOB, but then that means the object in question always has to be passed around when there is a live session, and users of the domain object have to know about LOBs. If on the other hand you use the common idiom of defining the field as a custom type which loads the whole LOB as a string or byte array, then you are _always_ going to be loading the LOB when you load the entity, not desireable for the common situation (for me, anyways) where the LOB field is only needed a small percentage of the time.

    So while I think lazy loading of general properties is not that big a deal, it'd be very very handy in terms of handling LOBs in a more flexible fashion, and is probably the number one feature on my Hibernate wishlist.

    Regards,
    Colin
  56. Lazy[ Go to top ]

    So while I think lazy loading of general properties is not that big a deal, it'd be very very handy in terms of handling LOBs in a more flexible fashion, and is probably the number one feature on my Hibernate wishlist.Regards,Colin
    As I said, I expect that we will provide this feature in Hibernate3. It is not very difficult to implement.
  57. Featuresets[ Go to top ]

    Suppose you have a table T1 one with column C1 to C9 being CHAR(4) and C10 being VARCHAR(3000). If 9 times out of 10, it would save a lot of storage space to split table T1 into
    - one table T1A with column C1 to C9 and foreign key pointing at a second table
    - T1B containing a key and column C10.

    I think it'd be really great to table T1A + T1B as 1 single object.

    I know that's not "good" database design. But it's seems to me that it would save a lot of disk space.

    We are actually planning to use hibernate on a project where we have that problem with sevral very big tables. So I'd be interessting to know what you would recommend.

    My apology for my poor english. I hope it still make sense.
  58. multitables[ Go to top ]

    Suppose you have a table T1 one with column C1 to C9 being CHAR(4) and C10 being VARCHAR(3000). If 9 times out of 10, it would save a lot of storage space to split table T1 into - one table T1A with column C1 to C9 and foreign key pointing at a second table- T1B containing a key and column C10.I think it'd be really great to table T1A + T1B as 1 single object.I know that's not "good" database design. But it's seems to me that it would save a lot of disk space.We are actually planning to use hibernate on a project where we have that problem with sevral very big tables. So I'd be interessting to know what you would recommend.My apology for my poor english. I hope it still make sense.
    Well, if you insist. If it were me, I would probably map it as two classes with an association. I like very finegrained classes. But like I said, we support this feature in Hibernate3 so you can do it if you want.
  59. multitables[ Go to top ]

    Thanks for your reply
  60. Do not overdesign[ Go to top ]

    Julien,

    I suggest you talk to your DBA. The situation with
    big fields is common. Oracle (I am sure other DB also)
    uses only space you need. Store 5 chars in Varchar2(3000)
    and it will take 5 chars on disk.

    Gavin,

    Looks like "Progection" is a "View" in db-parlance.
    I , again, suggest collaboration developer-DBA to use
    database views (if available).

    Work with DBAs!
    Know your DB!
    2+2=4 !!!!

    :-)
  61. Do not overdesign[ Go to top ]

    Looks like "Progection" is a "View" in db-parlance.
    No, a projection is what you put between SELECT and FROM ;-)
    It means selecting the columns of table(s).

    Mark
  62. Re: Do not overdesign[ Go to top ]

    Julien,I suggest you talk to your DBA. The situation withbig fields is common. Oracle (I am sure other DB also)uses only space you need. Store 5 chars in Varchar2(3000)and it will take 5 chars on disk.
    Well, things are not that simple. I do not know the exact format of storing varchars in Oracle, but I would suppose it employs some kind of a tree or allocation table. Which means, that each value eats up additional 2, 4 or 8 or even more bytes to store the pointer and and real length. For values shorter than 20 characters I use CHAR, for longer values I use VARCHAR. Access for fixed-size fields is supposed to be faster. For a VARCHAR(3000) I would not even bother to lose couple of bytes on each row. I never have built terabyte-sized billing databases though ;) I would think that a pointer to empty value is not even stored in the respective database row.
  63. Of course you can accomplish a great deal all from within emacs!

    While I generally agree that many/most experts prefer textual interfaces to GUI ones when available, I would say the an excellent GUI can't be beat. Trouble is, there just aren't that many excellent one out there.

    Sometimes NOT providing a GUI simply means you aren't able to create a good one ;-)

    We should, at least, acknowledge and appreciate the effort.

    Of course even "good code" is hard enough to produce.
  64. There is no difference between a GUI and an XML DTD. Both define the schema and the boundaries you are working in. You still have to learn on which icon and button to click in what situation. You still have to learn which element or attribute to use in what situation. The quality of the GUI or DTD is what influences that part, of course. But the issue is really learning _what_ to do, not _how_.

    Reality Check: I can remember 1 (one) question about a GUI mapping tool on the Hibernate forum in about one year. I think that learning ORM is a much bigger problem than learning how to write XML or how to use a mouse.
  65. Language matters[ Go to top ]

    There is no difference between a GUI and an XML DTD.
    There is a difference in the language(s) you use. Language Design DOES matter. If you don't think so, then feel free to stick with assembly :-) And "yes" a graphic interface is, itself, a language.
    But the issue is really learning _what_ to do, not _how_.
    True, in principle; in practice, if "how" is too complicated most will never figure out "what". You should be able tell if you're having trouble with the algorithm or the implementation.
    I think that learning ORM is a much bigger problem than learning how to write XML or how to use a mouse.
    I would agree, but why compound the difficulty?
  66. Language matters[ Go to top ]

    I do not like to read XML, but there is no problems to write it, my favorite IDE can help too. I do not understand how it is more easy to read GUI "language".

    BTW it must not be a very big problem to transform metadata XML files to SVG if somebody prefer to read pictures.
  67. The "User interface" is for sissys is a typical statement of middleware oriented developers to appear cool and top-notch. And definitely you are: You are of the 10% of developers who are more efficient digging through xml with vi. Congratulations! Fact though is, that the other 90% _are not_ as efficient.
    Without a UI, they need 2 or 3 times of the time to do the same exact thing.

    It's naive to assume UI's are not necessary. By not providing a great UI to a great application you are reducing it to something relatively mediocre. It is like you have a great product but you have neither sales nor marketing. I understand that UI programming of any sort is considered a burden as well as something that requires a "inferior" skillset, which is a rather sad misconception.

    It's fine with me if you as a developer think that nothing beats vi and XML.
    However, try to think of yourself as a member of a minority (or elite, which definitely sounds better).
  68. Me or him?[ Go to top ]

    Please don't confuse me (Jason) with him Gavin King

    Perhaps I was too subtle. I'm actually in favor of good GUIs.

    I did agree that many an expert prefers a text-based interface over a GUI but I sure don't get any joy from editing XML, especially in "vi". XML ain't for humans anyway. Never could figure out who thought it was.

    "Programs must be written for people to read, and only incidentally for machines to execute."

    - Abelson and Sussman, SICP, preface to the first edition

    I would also refer you to Succinctness is power along with my previous links.

    I wouldn't put XML in this category. I'm prefer to use the best language for the job, GUI or otherwise, period.

    Anyway, constructive criticism is good. But please which way you aim.

    Thanks.
  69. While I generally agree that many/most experts prefer textual interfaces to GUI ones when available, I would say the an excellent GUI can't be beat. Trouble is, there just aren't that many excellent one out there.
    JDX OR-Mapper comes with JDXStudio GUI tool. Here are a few highlights:

    - Excellent packaging of all the needed functionality to simplify mapping configuration (defining and verifying OR-Mapping, creating and reverse-engineering database schema)
    -Well-organized, color-coded panels for quick navigation
    -Extensive online help available at every step of the way
    -Easy to leverage legacy data for OR-Mapping
    -OneClickRevelation™ provides instant and interactive insight into your data without a single line of programming
     
    Additionally, JDX mapping is simple, human-readable, and easily comprehensible. There is no need to struggle with complex XML files.

    Try a free eval version of JDX and let's know what you think.

    Regards,

    -- Damodar Periwal
    Software Tree, Inc.
    Simplify Data Integration
  70. Featuresets[ Go to top ]

    Since, unlike most competing products, we have always supported projection in the query language, we have never needed (1), indeed, we believe it is a misfeature.

    Gavin,

    Is it possible to load an object "sparsely" using projection? I was under the understanding that you either load the whole thing (inheritance aside) or use projection and get back something other than the object, eg a scalar value.

    We have an object with lots of properties that we want only want to load part of. If (1) is a misfeature, how do you suggest we do this?

    cheers,

    David
  71. Please Don't Say That Ever Again[ Go to top ]

    I have recommended Hibernate for our projects in the past and when we see the need for ORM again, will probably recommended it again. However, we often compete against vendors who use comments like your "GUIS ARE FOR SISSIES!" as proof that the open source community is a collection of surly geeks who do not value the user.

    Anyone who has dealt with both sides of the aisle knows that proprietary software vendors actually almost always are horrific at actually helping people solve problems caused by their software. Unfortunately, comments like "GUIS ARE FOR SISSIES!" will help them keep doing what many of them have done for a long time-charge your boss or the client big $$$ to make them feel good about buying the product and glossing over that whole "actually works" thing.
  72. GUIS ARE FOR SISSIES![ Go to top ]

    Oh please, activate that sense of humor: my comment was accompanied by a wink ";-)", and my actual argument was really that we do care about the user! We care enough to not try and lure them in with shiny baubles that turn out to be useless in the long run.

    If you actually bothered to read my posts, you would see that I am arguing in favor of a /better/ approach, namely JSR-175 annotations, which will soon be standardized for ORM by the JSR-220 (Simplified EJB) spec. I don't see much room for GUIs when OR mapping metadata looks like this:


    @Entity @Table(name="ITEM")
    public class Item {

        @Id @Column(name="ID")
        private Long id;

        @Column(name="DESC")
        private String description;

        @ManyToOne @Column(name="SELLER")
        private User seller;

    }

    Actually, considering defaulting, it will really turn out looking more like this in practice:

    @Entity
    public class Item {

        @Id private Long id;

        @Column(name="DESC")
        private String description;

        private User seller;

    }
  73. GUIS ARE FOR SISSIES![ Go to top ]

    Gavin

    Do you think it’s really a good idea to annotate properties with database field names in the _code?_.
    Although C# supports Attributes, in Objectspaces they keep the property mappings out of the program code.
    http://longhorn.msdn.microsoft.com/lhsdk/ndp/daconmappingobjectproperties.aspx
    Why do you think they are doing this? Just interested in your viewpoints.

    Pratheep P
  74. Annotations[ Go to top ]

    Well, yes, I guess I do think it is a good idea ;-)

    People have been using XDoclet + Hibernate in this way (I've used it myself and like it), and have experienced great success!

    And with code folding support in your IDE, you will simply be able to suppress the annotations from your view of the code, when you don't want to think about them. In addition, there will be platform-level support for overriding those annotations at deployment time.

    OTOH, why do you think it is *not* a good idea? :-)

    P.S. Java is light years ahead of .Net for ORM technology, so I'm not really paying much attention to microsoft's stuff here....
  75. Annotations[ Go to top ]

    Thank you for your reply

    <gavin>
    OTOH, Why do you think it is *not* a good idea? :-)
    </gavin>

    Well. It was just feeling, after going great lengths to decouple the object model from the relational model why back again binding them. It’s just a feeling and I’m unable to give you a convincing technical reason though.:-).

    Pratheep P
  76. Annotations[ Go to top ]

    Instead of " decouple the object model from the relational model" I should have said " decouple relational schema from object model"

    Pratheep P
  77. Annotations[ Go to top ]

    Instead of " decouple the object model from the relational model" I should have said " decouple relational schema from object model"Pratheep P
    Probably I do not understand this idea, bu this decoupling looks useless.
    Why do you need two decoupled models and integration (mapping), is it something wrong to have single model (relational) and to use objects just as data structures (static or dynamic) and "helpers" ? It is possible to drop object model, but you need relational model any way and I see no meaning to do modeling twice.
  78. Annotations[ Go to top ]

    I know your stance towards ORM tools in general from other threads.

    You should check this out:

    http://www.theserverside.net/news/thread.tss?thread_id=25798

    Especially note Ted Neward’s, and Rod Johnson’s Arguments.

    Pratheep P
  79. Annotations[ Go to top ]

    Should add:

    I’m exactly doing the same thing you are suggesting in most of my projects when there are not much/simple business rules.

    Pratheep P
  80. Annotations[ Go to top ]

    I know your stance towards ORM tools in general from other threads. You should check this out:http://www.theserverside.net/news/thread.tss?thread_id=25798Especially note Ted Neward&#8217;s, and Rod Johnson&#8217;s Arguments.Pratheep P
    I am not ORM enemy, but I am owerdesign and RDBMS ignorance enemy.
  81. Annotations[ Go to top ]

    Then I'm with you!..

    The reason for my original question to Gavin on this one was that when you add annotations to properties I felt the ORM framework (almost)degrades to the solution you were proposing. Thats why I asked. Maybe I'm missing something here big time. I'll be in a better position to understand this after the spec is released I guess.

    Regards

    Pratheep
  82. Annotations[ Go to top ]

    Then I'm with you!..The reason for my original question to Gavin on this one was that when you add annotations to properties I felt the ORM framework (almost)degrades to the solution you were proposing. Thats why I asked. Maybe I'm missing something here big time. I'll be in a better position to understand this after the spec is released I guess.RegardsPratheep
    I think it is a very good idea to keep table names and field names in code, it helps to read mapping and to refactor code, tools can help to read XML, but think it is very good if I can read my code with text utils like "more". I do not want to hide database, it looks like both Hibernate and Cayenne do not
    hide database like some standard tools.
    I did a lot of owerdesign and useless owerabstraction mistakes myself and I am sure it must be more strong and pragmatic reasons to use some design than abstraction and objects, I think abstraction is not a good reason to use external files for mapping too.
  83. Annotations[ Go to top ]

    I agree with you in general.

    In fact the small library I use for .NET data access, works the same way you suggested. It keeps the table/field info in the code as attributes and uses a few helper classes.

    But keeping mappings out in xml has its uses.

    For example MS Objectspaces keeps the table mapping in an xml file. I guess you know Objectspaces will be part of Longhorn and will be used by WinFs. This allows MS to use the same ORM library to access different data stores uniformly. I do not think you can get this flexibility if you annotate your properties with field names. We use xdoclet to minimize coding. But making this part of the solution itself didn’t look elegant. But as I said earlier I may change my mind when I see the spec.


    Pratheep P
  84. Annotations[ Go to top ]

    Grrr..

    "ORM library" = "Object Model"

    Pratheep P
  85. Annotations[ Go to top ]

    I am not sure about current objectspaces status, but it was a toy when I tried to learn about it even JDO pre 1.0 was better for RDBMS access. This way is to add abstraction, transparence, ..., but it is a populism and probably for toys only or for trivial parts in applications (all ways are good to solve trivial problem). I do not know all ORM solutions, but I think hibernate is the most pragmatic compromise at this time. OJB is an interesting framework too, I have used ODMG interface and probably it was a mistake, "native" API looks more pragmastic too.
  86. Annotations - ObjectSpaces[ Go to top ]

    Hi Pratheep,

    Interesting thread. I just wanted to clarify something.
    I guess you know Objectspaces will be part of Longhorn and will be used by WinFs.
    As far as I am aware, ObjectSpaces will use WinFS rather than the other way around. Have you heard otherwise?

    - Chris
  87. Annotations and Decoupling[ Go to top ]

    Instead of " decouple the object model from the relational model" I should have said " decouple relational schema from object model"Pratheep P
    Probably I do not understand this idea, bu this decoupling looks useless.Why do you need two decoupled models and integration (mapping), is it something wrong to have single model (relational) and to use objects just as data structures (static or dynamic) and "helpers" ? It is possible to drop object model, but you need relational model any way and I see no meaning to do modeling twice.
    Well there are cases when you need to do such decoupling. If you plan to deploy your software on existing databases of multiple customers decoupling becomes a life saver. I worked on one such project and know of at least two more, so I assume this is not all that uncommon when you sell a product in a vertical market and have a requirement to integrate it with in-house databases.

    IMO, annotations may be a good solution if you are aware of its limitations, but it is not really superior to external mapping.
  88. Annotations and Decoupling[ Go to top ]

    We encountered this situation a few months ago:

    We noticed a set of applications require discussion forum like functionality, where the table formats are identical but will have different table names/fieldnames across applications. We developed a library to support this and kept the table/field mapping in an xml file. We reused the same library across all the projects just by changing the configuration file. A tool like Hibernate will solve this elegantly as it is now. But not when you compile table information in code

    Pratheep P
  89. Cayenne M7 Release[ Go to top ]

    Folks,

    While we were having this nice discussion about the merits of GUI tools, a new milestone of Cayenne was released. Check it out at http://objectstyle.org/cayenne/

    The new release has more of the same :-)

    In addition to the numerous bug fixes, it contains complete CayenneModeler support for all types of Cayenne queries, including recent SQLTemplate. Folks familiar with iBatis will find SQLTemplate very useful - it allows to create dynamic SQL for complex queries that are not very well expressed in standard ORM terms (and customize them by DB dialect). The difference from iBatis is that it uses Velocity for scripting instead of XML and (surprise) is integrated with normal Cayenne ORM features.

    Enjoy!
  90. IMO, we have to go one abstract layer higher -> go for MDA (MOF, XMI, UML, etc.). Using UML to design your object model makes you independent of those GUI builders. Surely you will need a UML GUI tool afterwards but you have a lot of choices of such UML tools (Poseidon, MagicDraw, etc. etc.).

    After using AndroMDA I won't ever go back to those GUI builders or pure XML approach:
    1. Model your object model with UML (PIM).
    2. Mark those entities with the stereotypes.
    3. Generate all the Java classes using the cartridges available (Hibernate, EntityBean, later JDO, maybe also for Cayenne?).
    4. Compile (XDoclet, Javac, etc.).
    5. Run.

    Pretty simple and powerful. No need to fight whether with or without GUI or with or without XML... ;-)

    As a small introduction I integrate a lot of Open Source tools (AndroMDA, JOnAS, Enhydra, Hibernate, etc.) within EJOSA:
    Documentation:
    http://prdownloads.sourceforge.net/ejosa/ejosa-revo-doc.pdf?download

    The process:
    http://ejosa.sourceforge.net/ejosa-images/ejosa-template-process-matrix.jpg

    Cheers,
    Lofi.
    http://www.openuss.org
  91. Scary thing in cayenne[ Go to top ]

    I'm hibernate user, and will remain it.
    It's not lack of xdoclet tags/plugins to generate mapping files ( being xdoclet commiter I can write them very fast )
    which turns me down.

    It's requirement to subclass from certain class or implement
    interface. This means, that I must make available cayenne classes everywhere I use my model beans. And I would prefer
    to be free in design of my class hierarchy.

    And while we are at it, hibernate got better choice of
    relation mappings.
  92. License?[ Go to top ]

    No one has mentioned the licensing differences.
  93. As JBoss is notorious for dual licenses, hibernate too will follow the same path soon, one Enterprise Hibernate and the other one we have build from CVS (Fedora Hibernate) Peace, DJ