Difference between Hibernate's get() and load()?

Home

News: Difference between Hibernate's get() and load()?

  1. Ganeshji Marwaha, in "Hibernate - Difference between session's get() and load()," shows how load() can optimize Hibernate's performance compared to get(), by avoiding trips to the database. With Hibernate now being a JPA implementation, this might or might not remain to be the case.
    Many... Every time a Bid is placed, is it wise to hit the database and retrieve the corresponding Item just to supply it as a reference? I guess not. That is where session.load() comes in. All the above scenarios remaining the same, if you just used session.load() instead of get(), hibernate will not hit the database. Instead it will return a proxy, or an actual instance if it was present in the current session, and that can be used to serve as a reference. What does this buy you? At least 2 advantages. First, you save a trip to the database. Second, the error handling code just got elegant.
    One hopes that JPA automatically provides caching through the EntityManager in Hibernate, making tips like this slightly less valuable - Hibernate folks, care to chime in?

    Threaded Messages (52)

  2. Lazy loading[ Go to top ]

    EntityManager in JPA has the getReference() method, which according to the javadocs does the following... Get an instance, whose state may be lazily fetched.
  3. Being an avid hibernate fan, I have always defended it in my organization when people throw undue criticism at it in order to protect themselves.
    It's good to know that Ganesh is keeping an open mind about things. But seriously, I fail to see how having to know all this hibernate specific esoterica is simplifying things. I kind of feel like JDBC just needed a little OO polish and they created a whole new platform. SQL is probably one of the most commonly understood languages in the world. It's not 100% uniform but many people know it. More people know it than Java and vastly more people know it than HQL. Why do so many people want to cast it aside for this tool? I'd understand if Hibernate made things much easier but it doesn't as far as I can tell. Maybe for very trivial things but it basically got in the way for anything more complex.
  4. I fail to see how having to know all this hibernate specific esoterica is simplifying things. I kind of feel like JDBC just needed a little OO polish and they created a whole new platform.
    JDBC is mapping of relational databases and need more than a little polish to turn into something OO like.
    I'd understand if Hibernate made things much easier but it doesn't as far as I can tell. Maybe for very trivial things but it basically got in the way for anything more complex.
    Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary. All of this boils down to one thing: OO . If you think that JDBC is an alternative you are not thinking in terms of OO (unfortunately you are not alone).
  5. I fail to see how having to know all this hibernate specific esoterica is simplifying things. I kind of feel like JDBC just needed a little OO polish and they created a whole new platform.


    JDBC is mapping of relational databases and need more than a little polish to turn into something OO like.

    I diasgree, having done it. It wasn't difficult.
    I'd understand if Hibernate made things much easier but it doesn't as far as I can tell. Maybe for very trivial things but it basically got in the way for anything more complex.


    Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary.

    All of this boils down to one thing: OO . If you think that JDBC is an alternative you are not thinking in terms of OO (unfortunately you are not alone).
    You are assuming you are in possession of the ultimate truth on the matter. I can tell you that you are wrong. I am thinking of this from an OO perspective. Hibernate is basically a minor improvement of entity beans. This is not the kind of OO we need.
  6. I fail to see how having to know all this hibernate specific esoterica is simplifying things. I kind of feel like JDBC just needed a little OO polish and they created a whole new platform.


    JDBC is mapping of relational databases and need more than a little polish to turn into something OO like.



    I diasgree, having done it. It wasn't difficult.

    I'd understand if Hibernate made things much easier but it doesn't as far as I can tell. Maybe for very trivial things but it basically got in the way for anything more complex.


    Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary.

    All of this boils down to one thing: OO . If you think that JDBC is an alternative you are not thinking in terms of OO (unfortunately you are not alone).


    You are assuming you are in possession of the ultimate truth on the matter. I can tell you that you are wrong. I am thinking of this from an OO perspective. Hibernate is basically a minor improvement of entity beans. This is not the kind of OO we need. Could you elaborate on the subject and describe the kind of OO you need?
  7. I am thinking of this from an OO perspective. Hibernate is basically a minor improvement of entity beans. This is not the kind of OO we need.
    Could you elaborate on the subject and describe the kind of OO you need?
  8. I fail to see how having to know all this hibernate specific esoterica is simplifying things. I kind of feel like JDBC just needed a little OO polish and they created a whole new platform.

    JDBC is mapping of relational databases and need more than a little polish to turn into something OO like.



    I diasgree, having done it. It wasn't difficult.

    I'd understand if Hibernate made things much easier but it doesn't as far as I can tell. Maybe for very trivial things but it basically got in the way for anything more complex.

    Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary.

    All of this boils down to one thing: OO . If you think that JDBC is an alternative you are not thinking in terms of OO (unfortunately you are not alone).

    You are assuming you are in possession of the ultimate truth on the matter. I can tell you that you are wrong. I am thinking of this from an OO perspective. Hibernate is basically a minor improvement of entity beans. This is not the kind of OO we need.
    I agree with James. The use of hibernate increases the complexity and therefore slow down the development process. I have been using hibernate for a long time and I don't see the benefit of using it. It is not worth using hibernate in Java at all, because using SQL and retrieving it to objects are still better in terms of usage and also maintenance.
  9. I fail to see how having to know all this hibernate specific esoterica is simplifying things. I kind of feel like JDBC just needed a little OO polish and they created a whole new platform.

    JDBC is mapping of relational databases and need more than a little polish to turn into something OO like.





    I diasgree, having done it. It wasn't difficult.

    I'd understand if Hibernate made things much easier but it doesn't as far as I can tell. Maybe for very trivial things but it basically got in the way for anything more complex.



    Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary.

    All of this boils down to one thing: OO . If you think that JDBC is an alternative you are not thinking in terms of OO (unfortunately you are not alone).

    You are assuming you are in possession of the ultimate truth on the matter. I can tell you that you are wrong. I am thinking of this from an OO perspective. Hibernate is basically a minor improvement of entity beans. This is not the kind of OO we need.


    I agree with James. The use of hibernate increases the complexity and therefore slow down the development process. I have been using hibernate for a long time and I don't see the benefit of using it. It is not worth using hibernate in Java at all, because using SQL and retrieving it to objects are still better in terms of usage and also maintenance.
    It certainly isn't for everyone. We have definitely benefited from our use of Hibernate. Our development is faster, the code definitely more maintainable, and performance has been great. I couldn't disagree with your more.
  10. I fail to see how having to know all this hibernate specific esoterica is simplifying things. I kind of feel like JDBC just needed a little OO polish and they created a whole new platform.

    JDBC is mapping of relational databases and need more than a little polish to turn into something OO like.





    I diasgree, having done it. It wasn't difficult.

    I'd understand if Hibernate made things much easier but it doesn't as far as I can tell. Maybe for very trivial things but it basically got in the way for anything more complex.



    Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary.

    All of this boils down to one thing: OO . If you think that JDBC is an alternative you are not thinking in terms of OO (unfortunately you are not alone).

    You are assuming you are in possession of the ultimate truth on the matter. I can tell you that you are wrong. I am thinking of this from an OO perspective. Hibernate is basically a minor improvement of entity beans. This is not the kind of OO we need.


    I agree with James. The use of hibernate increases the complexity and therefore slow down the development process. I have been using hibernate for a long time and I don't see the benefit of using it. It is not worth using hibernate in Java at all, because using SQL and retrieving it to objects are still better in terms of usage and also maintenance.
    I think it matter from which point of view you see it. Is the object the first class citizen or is it the database row. I, who look at from the object point of view, see the relational database as something I have to twist and stretch to do what I want (I would like to have an OO DB). If you look at it from the relational database view the object (java object) is hinder you have to overcome.
  11. I think it matter from which point of view you see it. Is the object the first class citizen or is it the database row. I, who look at from the object point of view, see the relational database as something I have to twist and stretch to do what I want (I would like to have an OO DB). If you look at it from the relational database view the object (java object) is hinder you have to overcome.
    I don't look at the Object as hinderance. The Object is whatever I need it to be. Objects are a great way to associate logic with data but they aren't very good representations of data. Beans are pretend OO. What I mean is that JavaBeans are Java pretending to be SmallTalk. But Java isn't SmallTalk so we something external to Java to work with them effectively. The key to Objects are what they do, not what they hold. That's a struct, not an Object.
  12. Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary.
    This statement is laughable. No one was able to create complex domain models before hibernate? You can't possibly be serious. There's nothing you can do with Hibernate that you can't do without it.
  13. Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary.


    This statement is laughable. No one was able to create complex domain models before hibernate? You can't possibly be serious. There's nothing you can do with Hibernate that you can't do without it.
    The argument that you can do it your self is usually rather weak. Why do you need Java? You could write it your self! Why Do you need a database? .... and so on. Of course you could implement complex domain models without Hibernate but then you would have to re implement everything yourself. This could only be explained by the Not Invented Here syndrome.

  14. The argument that you can do it your self is usually rather weak. Why do you need Java? You could write it your self! Why Do you need a database? .... and so on.
    Of course you could implement complex domain models without Hibernate but then you would have to re implement everything yourself. This could only be explained by the Not Invented Here syndrome.
    Java provides huge advantages in productivity, complexity, reliability and a smaller gap between the model of my solution and its implementation, so Java has a value proposition that I find compelling. For me, Hibernate does not offer enough value to make it worth using. Hibernate's caching is useless because I work in environments with diverse technologies. Other non-Java applications access the databases, if not now, then within the next few years. In 20 years of using RDBMS, I’m still using the same database products but my programming language has changed many times. Fortunately my RDBMS caches result sets already. Hibernate does not solve complex mapping problems other than for reads. The relational databases I have to work with are sometimes well done and sometimes a VSAM file structure dumped into table form. They do not have a one-to-one table to object mapping. If it did I'd either have bad objects or a bad physical schema. When the database is denormalized and the mappings are all over the place, my rules for update, delete and even insert can become quite complex. I've never seen a tool magically generate code that understands the rules. So an O-R mapping tool that helps me get started by generating some stubs and skeletons is nice, but who needs the run-time? I’m not really slamming Hibernate per se, it is just that the O-R data abstraction layer does not belong in a platform that is tightly bound to a specific language or runtime. In addition there are no and probably never will be any silver bullets to solve O-R mapping. If the RDBMS schemas were developed from the same model as the objects (a good practice for green field projects) then at least you could keep the mappings relatively simple and tools could work. But in the world of really big organizations that are around for a long time, that sort of thing is like a bloom in the desert – rare, beautiful and short-lived.
  15. ummmm[ Go to top ]

    Hibernate's caching is useless because I work in environments with diverse technologies. Other non-Java applications access the databases, if not now, then within the next few years.
    The fact that you have multiple applications accessing the same DB essentially invalidates any caching strategy outside of the DB itself. So you should have more correctly said that Hibernate, and all other caching mechanisms outside of the DB, are useless to you.
    Hibernate does not solve complex mapping problems other than for reads. The relational databases I have to work with are sometimes well done and sometimes a VSAM file structure dumped into table form. They do not have a one-to-one table to object mapping. If it did I'd either have bad objects or a bad physical schema. When the database is denormalized and the mappings are all over the place, my rules for update, delete and even insert can become quite complex.
    Your problems with Hibernate can be simply attributed to a lack of understanding of Hibernate, what it is capable of and how to use it properly.
    Hiberate's transitive persistence mechanisms allows for super fancy delegation of CRUD operations throughout a huge domain model by simply issuing a persistence operation on one top "parent" object. A simple domain model with "one-to-one" table to object mapping is quite possibly the most primitive design that Hibernate supports. I suggest you check out the Hibernate Reference doc and read up on object composition, composite identifiers, many-to-many relationships with join tables, inheritence, list/bag/set collection semantics, transitive persistence rules at the object/table level and transaction management....try out some examples...then come back and gripe once you know what your talking about.
  16. Re: ummmm[ Go to top ]

    Hibernate's caching is useless because I work in environments with diverse technologies. Other non-Java applications access the databases, if not now, then within the next few years.

    The fact that you have multiple applications accessing the same DB essentially invalidates any caching strategy outside of the DB itself. So you should have more correctly said that Hibernate, and all other caching mechanisms outside of the DB, are useless to you.

    My goodness! Are you a Hibernate fanboy? Yes, my comment applies to all caching schemes outside the database. That should be obvious, but we were talking about Hibernate.
    Hibernate does not solve complex mapping problems other than for reads. The relational databases I have to work with are sometimes well done and sometimes a VSAM file structure dumped into table form. They do not have a one-to-one table to object mapping. If it did I'd either have bad objects or a bad physical schema. When the database is denormalized and the mappings are all over the place, my rules for update, delete and even insert can become quite complex.

    Your problems with Hibernate can be simply attributed to a lack of understanding of Hibernate, what it is capable of and how to use it properly.

    Hiberate's transitive persistence mechanisms allows for super fancy delegation of CRUD operations throughout a huge domain model by simply issuing a persistence operation on one top "parent" object.

    A simple domain model with "one-to-one" table to object mapping is quite possibly the most primitive design that Hibernate supports. I suggest you check out the Hibernate Reference doc and read up on object composition, composite identifiers, many-to-many relationships with join tables, inheritence, list/bag/set collection semantics, transitive persistence rules at the object/table level and transaction management....try out some examples...then come back and gripe once you know what your talking about. You have no idea of what I’ve tried or not tried. I’ve tested schemes like Hibernate and TopLink and others for years looking to simplify the implementation of O-R mapping. The main appeal of these things is how much they can generate on their own. Once you begin doing mappings you have to begin comparing the level of effort required to that of hand coding. Unfortunately, when the mappings become complex its advantage over hand coding begins to disappear. Rules such as – “a deletion of this object means nulling certain columns in certain rows of tables x and y, deleting a row in table z and supplying some application defined non-value (nulls were not used) in other columns of table a” require effort to understand, code and test whether you are using a map or hand coding. Also consider that Hibernate is language/run-time centric, meaning you will have to re-implement these rules for the non-Java applications. I always seem to find other alternatives that have a greater strategic value and are in the worst cases not much more difficult to implement than with Hibernate. It is rarely 100% satisfactory of course – always trade-offs. So, in my situations the caching has no value and the “magic” is not so magical when the going gets rough and it’s a language run-time specific solution. Whoop dee do! I’m not saying that no one should use it. I’m saying that its value is limited in larger or technically diverse enterprises. Look, Java is great, but languages and run-times, come and go far more frequently than databases. Few if any large enterprises use one language or run-time to execute all of their applications. I’d rather implement a solution for data abstraction that was not so tightly coupled to my application run-time. What is needed is a solution that runs under the database connector (jdbc, odbc), but above the database so it is independent of the run-time and the rdbms. Gee, that might be called an intermediation layer.
  17. Re: ummmm[ Go to top ]

    Your problems with Hibernate can be simply attributed to a lack of understanding of Hibernate, what it is capable of and how to use it properly... [blah blah blah stuff we all know about]
    You have no idea of what I’ve tried or not tried.
    Just a statement of solidarity, William. Maybe we are wrong and Hibernate will soon conquer the world because of it's inherent superiority but this kind of statement is beneath contempt. It's not just hibernate fans, or software people either. This kind of BS is so prevalent that I think most people believe it's actually a valid argument. Assuming that because someone disagrees with you that they lack intelligence, knowledge or both is arrogant and immature. It's way too prevalent in a group of people who should ostensibly have a pretty good handle on logic.
  18. Re: ummmm[ Go to top ]


    Your problems with Hibernate can be simply attributed to a lack of understanding of Hibernate, what it is capable of and how to use it properly... [blah blah blah stuff we all know about]

    You have no idea of what I’ve tried or not tried.


    Just a statement of solidarity, William. Maybe we are wrong and Hibernate will soon conquer the world because of it's inherent superiority but this kind of statement is beneath contempt. It's not just hibernate fans, or software people either. This kind of BS is so prevalent that I think most people believe it's actually a valid argument. Assuming that because someone disagrees with you that they lack intelligence, knowledge or both is arrogant and immature. It's way too prevalent in a group of people who should ostensibly have a pretty good handle on logic.
    You are right. Hibernate is not the ultimate expression of persistence technology. No doubt. But don't you do the same thing when you make claims like "it seems to me that people want to use it everywhere", to paraphrase you. Do you not at least imply a similar lack of intelligence, experience, or knowledge when you say "I don't understand why anyone would use such a tool." As I've written earlier, perhaps a tool can be popular for the right reasons, like say ABS, as opposed to popular like say, Brittany Spears. Having used various ORM tools, JDBC, and at writing such a thing as an ORM tool on a smaller scale, I can say that Hibernate does what it does well. It does provide value. In fact, I would argue that since some seemingly sharp people endorse it, surely that must be at least some value in the tool.
  19. Re: ummmm[ Go to top ]

    You are right. Hibernate is not the ultimate expression of persistence technology. No doubt.
    I didn't say that. Why do you insist on trying to read into what I have written? Why can't you just address what I wrote and not what you think I was thinking when I wrote it?
    But don't you do the same thing when you make claims like "it seems to me that people want to use it everywhere", to paraphrase you.
    What do you think 'seems' means?
    Do you not at least imply a similar lack of intelligence, experience, or knowledge when you say "I don't understand why anyone would use such a tool."
    I don't recall writing this and a couple attempts to search on part of that phrase turned up nothing. If you can point me to what exactly you are referring to I can address it. Even if I didn't write it, no, it isn't the same. Saying you don't understand something is not anything like saying someone else doesn't understand something. I think if you just read what was there and stopped projecting thought on the author you might be less offended by things.
    As I've written earlier, perhaps a tool can be popular for the right reasons, like say ABS, as opposed to popular like say, Brittany Spears.

    Having used various ORM tools, JDBC, and at writing such a thing as an ORM tool on a smaller scale, I can say that Hibernate does what it does well.
    I never said it doesn't work. I have more of a problem with the overall approach i.e. the design it requires. The problem I have with ORM tools in Java in general is that all the ones I have seen assume a design that uses beans or Objects that are used like beans. This is appropriate for certain things in an application but I think developers in general under-estimate the cost of using static structures in the general design of an application. I think there's a major illusion-of-control issue where developers feel comfortable with having a class with getters and setters because the property names are there on 'paper'. But when you use a tool like Hibernate or Spring, every thing is dynamically linked through reflection and/or bytecode engineering anyway. I have had to junk the 'right' way (in my estimation) of doing things in many cases because I had to work with beans. Instead of a configurable solution, one where some code has to be written for every change is forced upon me. To me, the things that Hibernate does for me are outweighed by how much work I have to do to get everything the way is needs to be for it to do things for me.
    It does provide value. In fact, I would argue that since some seemingly sharp people endorse it, surely that must be at least some value in the tool.
    That's a fairly weak argument but I don't argue that it doesn't add value. But I question whether many of the people using it know what value it adds. I think a lot of the experts that are using it are also using code generation. Projects that are using code generation for large portions of their project are in effect not writing code in Java but in some other type of language or proto-language. Hibernate and Spring are also essentially problem specific programming languages (Spring seems to be a very large set of these.) I'm not arguing that Java is the best solution (it's not) for all these problems but if we are going to be doing this, lets go all the way and use a real language and something based on XML.
  20. Re: ummmm[ Go to top ]

    lets go all the way and use a real language and something based on XML.
    should be: not something based on XML.
  21. more ummmm[ Go to top ]

    Maybe we are wrong and Hibernate will soon conquer the world because of it's inherent superiority but this kind of statement is beneath contempt. It's not just hibernate fans, or software people either. This kind of BS is so prevalent that I think most people believe it's actually a valid argument.
    I dont thoroughly believe Hibernate is the be-all-end-all solution to every problem. But i do believe it is much more useful then what people here are giving it credit for. And i believe that slamming the entire framework because it doesnt fit into someone's prehistoric DB structure or poorly-designed domain model is just ridiculous.
    Assuming that because someone disagrees with you that they lack intelligence, knowledge or both is arrogant and immature.
    I dont assume a general lack of intelligence on william's behalf rather a lack of understanding of hibernate...the topic at hand. But when william says things such as:
    Hibernate does not solve complex mapping problems other than for reads.
    or
    O-R data abstraction layer does not belong in a platform that is tightly bound to a specific language or runtime
    it really makes me wonder if he really understands the implications of such a comment. I find it rather difficult to imagine how one would decouple the OR abstraction layer from a specific language considering the objects that are generated in the mapping are indeed language specific. I guess what he is asking for is an Object Oriented Database.
    Rules such as – “a deletion of this object means nulling certain columns in certain rows of tables x and y, deleting a row in table z and supplying some application defined non-value (nulls were not used) in other columns of table a” require effort to understand, code and test whether you are using a map or hand coding.......What is needed is a solution that runs under the database connector (jdbc, odbc), but above the database so it is independent of the run-time and the rdbms. Gee, that might be called an intermediation layer.
    Gee, sounds perfect for a stored procedure....not a framework that deals with objects.
  22. Re: more ummmm[ Go to top ]

    Maybe we are wrong and Hibernate will soon conquer the world because of it's inherent superiority but this kind of statement is beneath contempt. It's not just hibernate fans, or software people either. This kind of BS is so prevalent that I think most people believe it's actually a valid argument.

    I dont thoroughly believe Hibernate is the be-all-end-all solution to every problem. But i do believe it is much more useful then what people here are giving it credit for. And i believe that slamming the entire framework because it doesnt fit into someone's prehistoric DB structure or poorly-designed domain model is just ridiculous.
    Why do you see a critique as being a 'slam'. My original comment was that when I see blogs an articles about hibernate explaining these esoteric issues that you need to know about to use hibernate, it makes me question the idea (that I have heard espoused) that Hibernate simplifies database access and updates. If you don't think Hibernate is simple and think that the benefits are found elsewhere, then I'm not going to contradict you because I don't know your context. I have specific reasons that I don't care for hibernate. I don't see why I shouldn't be allowed to express them without unfounded accusations of incompetence.
    Assuming that because someone disagrees with you that they lack intelligence, knowledge or both is arrogant and immature.

    I dont assume a general lack of intelligence on william's behalf rather a lack of understanding of hibernate...the topic at hand.

    But when william says things such as:
    Hibernate does not solve complex mapping problems other than for reads.
    or
    O-R data abstraction layer does not belong in a platform that is tightly bound to a specific language or runtime

    it really makes me wonder if he really understands the implications of such a comment.
    I question the second quote above because I though Hibernate was supported on more than one platform. But maybe he knows something more about that than I do. The appropriate response is to question the statments and propose counter arguments, not to say the equivalent of "you don't know know your ass from a hole in the ground, so shut up." That doesn't help anyone and it surely won't convince anyone of your argument.
    I find it rather difficult to imagine how one would decouple the OR abstraction layer from a specific language considering the objects that are generated in the mapping are indeed language specific. I guess what he is asking for is an Object Oriented Database.
    Why do you assume that's what he means? If I understand him, it's similar to my problem. Hibernate requires (as I understand it) creating lots of classes in order to get the data out of the database. These classes are not useful outside of Java. In my work, my goal is to get the data from a table to a queue or from a queue to a table. Hibernate doesn't give me much leverage here because it requires more work than just using dynamic approaches. If I had a highly static model of classes that were associated to the database, Hibernate might be a useful tool but I could also accomplish the same thing with other approaches. I think is delinquent to just assume a solution and when I've asked a lot of people why they chose Hibernate, they have no answer. Similarly, when I ask people what benefits they get from Hibernate they have no good answer or answers that I don't find all that convincing. I think there are definitely cases where it may be a great solution but I think that there are a lot of people using it based on hype.
  23. Re: more ummmm[ Go to top ]

    I dont assume a general lack of intelligence on william's behalf rather a lack of understanding of hibernate...the topic at hand.

    But when william says things such as:
    Hibernate does not solve complex mapping problems other than for reads.
    or
    O-R data abstraction layer does not belong in a platform that is tightly bound to a specific language or runtime



    I question the second quote above because I though Hibernate was supported on more than one platform. But maybe he knows something more about that than I do.
    Gentlemen, please tell me how Hibernate supports non-Java application runtimes in the middle tier such as CICS or Tuxedo. How about .NET or COM/DCOM? Is it elegant and wonderful? Was it easy to implement? How is the debugging working out for you? Hibernate is designed to work with the Java language and platforms (e.g. J2EE, Spring). And to an earlier comment I respond: Yes I do use stored procedures (esp. Oracle PL/SQL objects) for O-R quite often. My RDBMS rarely changes. I work with Oracle (and DB2) applications where the programming language of choice has change 3 or 4 times. I have never seen an RDBMS or other DBMS (IMS for example) replaced on a major enterprise system except as part of a rewrite or refactoring project. It is very risky and expensive. More often I see new applications using a different RDBMS if the current vendor has fallen out of favor. Some companies swap amongst DB2/UDB, Oracle and SQL Server just to keep them guessing. (If anyone thinks that by sticking with ANSI SQL you have architectural, design and code independence from your DBMS, then you've never done serious enterprise-level database design.)
  24. Re: more ummmm[ Go to top ]

    I question the second quote above because I though Hibernate was supported on more than one platform. But maybe he knows something more about that than I do.

    Gentlemen, please tell me how Hibernate supports non-Java application runtimes in the middle tier such as CICS or Tuxedo. How about .NET or COM/DCOM?
    Well, there's .NET version of Hibernate, which is kind of what I am getting at. But in general, I agree, it's pretty limited. Compared to SQL, hibernate has very limited support.
    (If anyone thinks that by sticking with ANSI SQL you have architectural, design and code independence from your DBMS, then you've never done serious enterprise-level database design.)
    While, again, I don't think this kind of 'if you think X you're an idiot' statement is necessary or contributes to a good discussion but I don't disagree with the idea that using ANSI SQL doesn't make your code portable (although it is a good thing to use it as much as possible.) However, I believe one of the goals of Hibernate is to help if not solve this issue. How well it does this is not something I am going to comment upon. I try to address this to some degree by not embedding SQL in my Java code which has the side benefit of making it a lot easier to read and modify.
  25. Re: more ummmm[ Go to top ]

    While, again, I don't think this kind of 'if you think X you're an idiot' statement is necessary or contributes to a good discussion but I don't disagree with the idea that using ANSI SQL doesn't make your code portable (although it is a good thing to use it as much as possible.) However, I believe one of the goals of Hibernate is to help if not solve this issue. How well it does this is not something I am going to comment upon. I try to address this to some degree by not embedding SQL in my Java code which has the side benefit of making it a lot easier to read and modify.
    James, I wasn't trying to come off as - "If you disagree you are an idiot", but maybe I did. It is just that people who have not been DBAs (as in physical design) for more than one RDBMS product or have done similar work for a non-trivial database, such as one that uses partitioning schemes or relies on RDBMS suppliesd failover and recovery schemes - often do not appreciate how much the physical implementation of a database depends on the product used. There are very serious issues and risks involved when changing the RDBMS used by an existing applications. Its a major reason why we change middlware and programming languges far more frequently than DBMS's. I'm always amazed by how many developers and manager seem to think they are somehow vendor independent because they stick to ANSI SQL. As to what Hibernate's goals are - I agree. I agree that we should try to isolate data management concerns from the rest of the application.
  26. Re: more ummmm[ Go to top ]

    James, I wasn't trying to come off as - "If you disagree you are an idiot", but maybe I did. It is just that people who have not been DBAs (as in physical design) for more than one RDBMS product or have done similar work for a non-trivial database, such as one that uses partitioning schemes or relies on RDBMS suppliesd failover and recovery schemes - often do not appreciate how much the physical implementation of a database depends on the product used.
    What you write here is so much more informative than what you wrote before. And you are right, a lot of people don't know these things. But people don't know what it is that they don't know and often don't know that they don't know something (very Rumsfeldian, no?) Someone might read this and realize that there's more to it than they might consider. By saying 'if you think X then you don't know Y' it not only comes across as an attack, it rules out the idea that someone could know Y and still think X. Anyway it's no big deal, I just think creates a lot of discord with little benefit.
    There are very serious issues and risks involved when changing the RDBMS used by an existing applications. Its a major reason why we change middlware and programming languges far more frequently than DBMS's.
    Yeah, I've been through it an it's not pretty.
  27. Re: more ummmm[ Go to top ]


    But when william says things such as:
    Hibernate does not solve complex mapping problems other than for reads.
    or
    O-R data abstraction layer does not belong in a platform that is tightly bound to a specific language or runtime

    it really makes me wonder if he really understands the implications of such a comment. I find it rather difficult to imagine how one would decouple the OR abstraction layer from a specific language considering the objects that are generated in the mapping are indeed language specific. I guess what he is asking for is an Object Oriented Database.

    A few points: I assure you I understand the “implications” and they are that Hibernate has limited value in many situations that are very common in large enterprises. OODBMS work great. I’ve used ObjectStore and Gemstone a number of times. When they are used as a middle tier cache though (with huge scalability benefits) I still have the problem of legacy backdoors – i.e. systems that cannot be routed through the OODBMS which may compromise my cache. What I would like is a JDO-type connector standard that all DBMS vendors support and that is accessible to all programming languages and platforms. Failing that I look at intermediation products that support access via ODBC and JDBC drivers. O-R mappings should not be language specific. Objects come from OOA which is not a language specific exercise. Domain objects (classes used for data, especially that which are serialized to queues and databases) especially should not have to include structures that cannot be implemented in any respectable programming language. If your O-R mappings are specific to Java, then you are either confused or you do not know how to object model data. Hell, I was implementing objects in ‘C’ 20 years ago because the OOP languages at the time either did not scale or were proprietary or both.
    Rules such as – “a deletion of this object means nulling certain columns in certain rows of tables x and y, deleting a row in table z and supplying some application defined non-value (nulls were not used) in other columns of table a” require effort to understand, code and test whether you are using a map or hand coding.......What is needed is a solution that runs under the database connector (jdbc, odbc), but above the database so it is independent of the run-time and the rdbms. Gee, that might be called an intermediation layer.

    Gee, sounds perfect for a stored procedure....not a framework that deals with objects.
    Yes, stored procedures and PL/SQL object work very nicely and give me O-R mappings that are independent of the programming language accessing them. My position is that these "frameworks", especially those that are language or platform limited are not all that useful in the work I do, so I guess you agree now. BTW, the work I describe is typical of what is happening in the largest and richest organizations - corporate, government, etc., in the world. It is where the preponderance of IT value is these days. Your government, the businesses you deal with and most of the major products you use (home, car, etc.) depend on these systems. That may bore you, but who cares?
  28. Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary.


    This statement is laughable. No one was able to create complex domain models before hibernate? You can't possibly be serious. There's nothing you can do with Hibernate that you can't do without it.

    The argument that you can do it your self is usually rather weak. Why do you need Java? You could write it your self!
    Another rhetorical debater [sigh]. The developers of Hibernate, 'did it themselves' (himself originally?) The reason I 'did it myself' is that I can't find anything that does it the way that makes sense for what I need. I'm considering creating an open source project for it. Kind of like the way Hibernate was created. The code is really quite trivial, actually. Mostly just generated wrappers.
    Why Do you need a database? .... and so on.
    Of course you could implement complex domain models without Hibernate but then you would have to re implement everything yourself. This could only be explained by the Not Invented Here syndrome.
    Why do you write code that uses Hibernate? Do you ave to do it all yourself? This is seriously insipid way to debate. Look at some of the other responses that disagree with me. These are people with brains. Learn from them.
  29. I fail to see how having to know all this hibernate specific esoterica is simplifying things. I kind of feel like JDBC just needed a little OO polish and they created a whole new platform.
    JDBC is mapping of relational databases and need more than a little polish to turn into something OO like.
    Yes, a little code generation from the database schema. No complex config and mapping files.
    I'd understand if Hibernate made things much easier but it doesn't as far as I can tell. Maybe for very trivial things but it basically got in the way for anything more complex.
    Quite the opposite. For very trivial things Hibernate, JPA and JDO is overkill but for complex domain models with inheritance it is necessary.
    For complex models you need even more complex Hibernate mapping files. Where is the advantage?
    All of this boils down to one thing: OO . If you think that JDBC is an alternative you are not thinking in terms of OO (unfortunately you are not alone).
    Oh no, not the mythical 'impedance mismatch' again!
  30. hibernate esoterica[ Go to top ]


    But seriously, I fail to see how having to know all this hibernate specific esoterica is simplifying things.
    Try ibatis then, it hits the sweet spot in letting you have your SQL and data mapping without excess conceptual OR overhead.
  31. But seriously, I fail to see how having to know all this hibernate specific esoterica is simplifying things.
    True enough, Hibernate ostensibly adds some complexity. But the learning curve is not terribly large, and once you have that tool in your bag, persisting an entire object graph of arbitrary depth becomes a one liner, something that would have required dozens of lines of JDBC code.
    I kind of feel like JDBC just needed a little OO polish
    To me, DBUtils is a "little polish." Personally, I think a full ORM provides quite a bit more utility.
    SQL is probably one of the most commonly understood languages in the world. It's not 100% uniform but many people know it. More people know it than Java and vastly more people know it than HQL.
    True enough. ORM is an advanced tool. Good tools require good developers. See Jason Carreira's blog.
    Why do so many people want to cast it aside for this tool?
    Vastly increased productivity. DAO methods often become one liners.
    I'd understand if Hibernate made things much easier but it doesn't as far as I can tell.
    I'd disagree. Spring and Hibernate as far as I can tell has been the killer app for Java web dev for the last few years. Between the databinding of Spring and Hibernate, developing web forms is massively simplified. Throw in DWR and you've got a stack that absolutely encourages and fosters building apps with complex, rich domain models, where the grunt work of the persistence layer is largely removed. About the only knock I have against Hibernate is that it sometimes produces unnecessary queries that are difficult to get rid of.
    Maybe for very trivial things but it basically got in the way for anything more complex.
    Agreed that Hibernate usage is more difficult if you don't have control of the database. For very f_cked up schemas yes, you may be better off not using Hibernate.
  32. But seriously, I fail to see how having to know all this hibernate specific esoterica is simplifying things.

    True enough, Hibernate ostensibly adds some complexity. But the learning curve is not terribly large, and once you have that tool in your bag, persisting an entire object graph of arbitrary depth becomes a one liner, something that would have required dozens of lines of JDBC code.

    I kind of feel like JDBC just needed a little OO polish


    To me, DBUtils is a "little polish." Personally, I think a full ORM provides quite a bit more utility.


    SQL is probably one of the most commonly understood languages in the world. It's not 100% uniform but many people know it. More people know it than Java and vastly more people know it than HQL.


    True enough. ORM is an advanced tool. Good tools require good developers. See Jason Carreira's blog.

    I'm not sure I follow your argument. The people I work with with 20+ years experience with data modeling and application design are not 'good developers' because they haven't become acquainted with the upstart called Hibernate? I beg to differ. Every argument I've ever heard about Hibernate (until now) is that it makes things easier. Now you are telling me it's too advanced for the average developer? Honestly, I think the main advantage of Hibernate is it makes it possible for developers that lack certain skills to succeed. The problems that Hibernate solves for people are often their ignorance of how to approach complex problems. It constrains the approach to something they can understand. I've been on the kind of team where it would have been great. The design starts with 'OK, we'll create a bean class for each table.' Then the team figures out how the beans will be used to fulfill the given requirements. Then the team determines how to get the data into the beans. At that point, would I want to use Hibernate? Damn straight.
    Why do so many people want to cast it aside for this tool?


    Vastly increased productivity. DAO methods often become one liners.
    Why do I need DAOs? This is where I start to get tired with the pro-Hibernate arguments. All the terrible advice in the J2EE design patterns is assumed to be 'the way' to do things. I am able to take my thin layer around JDBC and write a Java program that will write to and from arbitrary tables in around 100-200 lines of code (I wrote it with Jython which made it about 50 each for load and unload.)
    I'd understand if Hibernate made things much easier but it doesn't as far as I can tell.


    I'd disagree. Spring and Hibernate as far as I can tell has been the killer app for Java web dev for the last few years. Between the databinding of Spring and Hibernate, developing web forms is massively simplified. Throw in DWR and you've got a stack that absolutely encourages and fosters building apps with complex, rich domain models, where the grunt work of the persistence layer is largely removed. About the only knock I have against Hibernate is that it sometimes produces unnecessary queries that are difficult to get rid of.

    I guess what doesn't make sense for me with Hibernate is that it basically assumes that your Java classes are the 'real' model and the database is just some artifact of it. I see it pretty much the opposite. The database is real and the Java classes are are faint reflections of that data. Probably part of the reason is that I've never had the luxury of working with a DB where we weren't sharing the data with some other (usually legacy) code, often written in another language. The other problem I have with it is that it's all about beans. Beans may be good for your heart, but they make me fart and my coworkers don't appreciate that much.
    Maybe for very trivial things but it basically got in the way for anything more complex.


    Agreed that Hibernate usage is more difficult if you don't have control of the database. For very f_cked up schemas yes, you may be better off not using Hibernate.
    I guess I can see how Hibernate could really add value for the right kind of application. But I think the whole approach doesn't make sense for the kind of application that I have been writing lately. I'm generally streaming data from the database, doing a little work on it and then writing it to output. Loading the data into beans has almost no value to me. In fact, it's constraining because now, I can modify some SQL and add data to the stream with no compilation. Writing a bean for everything is just a big waste of time for me. However, if I were going to have a long lived data model in memory and have a lot of these classes anyway, I might see Hibernate as a good way to persist and load the Objects. However, what I found when I worked with it was that as soon as I started working with a long conversation and wanting to do things that weren't in the Hibernate play-book, I was doing all kinds of weird things to get it to work properly. Kind of like trying to steer a car with a broomstick while riding on the roof.
  33. Beans and farting[ Go to top ]

    Beans may be good for your heart, but they make me fart and my coworkers don't appreciate that much.
    I guess that makes you an ecological bomb when you program in Java, ain't it James ? :-))
  34. I'm not sure I follow your argument. The people I work with with 20+ years experience with data modeling and application design are not 'good developers' because they haven't become acquainted with the upstart called Hibernate? I beg to differ.
    Sorry James, no disrespect meant there. You said, "SQL is probably one of the most commonly understood languages in the world. It's not 100% uniform but many people know it. More people know it than Java and vastly more people know it than HQL." I interpreted that as you basically saying that junior devs will probably know SQL, but may not know Hibernate. So basically SQL has the benefit that it's a lower common denominator, more people know it. The same way more people know html than Java. And really, it's not Hibernate per se, it's ORMs. And frankly, and again, I mean no disrespect here, but I would think it be pretty rare to find a kick-_ss developer who wasn't familiar with ORMs, and in particular Hibernate. Hibernate's really become rather ubiquitous in the last few years, so much so that the next f_cking implementation of EJB basically equals Hibernate.
    Every argument I've ever heard about Hibernate (until now) is that it makes things easier. Now you are telling me it's too advanced for the average developer?
    It does make things easier. The same way using a CNC machine makes cutting aluminum easier. Simplifying complex problems typically requires complex tools. But once usage of the tool is mastered solving that complex problem is much easier than if you didn't have access to that tool, don't you think?
    Honestly, I think the main advantage of Hibernate is it makes it possible for developers that lack certain skills to succeed.
    I've seen this argument alot. Hibernate doesn't work well if you aren't well versed in SQL already. It's not a crutch for people who don't know SQL well, quite the contrary actually - you should only pick it up if you are already very comfortable with straight SQL.
    Why do I need DAOs? This is where I start to get tired with the pro-Hibernate arguments. All the terrible advice in the J2EE design patterns is assumed to be 'the way' to do things. I am able to take my thin layer around JDBC and write a Java program that will write to and from arbitrary tables in around 100-200 lines of code (I wrote it with Jython which made it about 50 each for load and unload.)
    Um, ok. I quite like DAOs myself. In any case, say I don't create any DAOs, the code to persist *any* object graph, *of arbitrary depth*, is still one line. save(Object entity) if we do it your way saves any persistent class. Uh, how many lines did you say it took you?
    I guess what doesn't make sense for me with Hibernate is that it basically assumes that your Java classes are the 'real' model and the database is just some artifact of it. I see it pretty much the opposite. The database is real and the Java classes are are faint reflections of that data.
    The database is just data. The application (read, the Java classes) manages data AND logic. So no, in my Java code your database is NOT the representation I want to work with.
    But I think the whole approach doesn't make sense for the kind of application that I have been writing lately. I'm generally streaming data from the database, doing a little work on it and then writing it to output. Loading the data into beans has almost no value to me. In fact, it's constraining because now, I can modify some SQL and add data to the stream with no compilation. Writing a bean for everything is just a big waste of time for me.
    Sounds like your app doesn't have a complex domain model. No, Hibernate probably isn't so useful in that instance, nor any other ORM.
  35. I would think it be pretty rare to find a kick-_ss developer who wasn't familiar with ORMs, and in particular Hibernate.
    Hi Michael, As a starter for ten, how about all the propeller heads who work in investment banking? I'd be quite surprised if those people working in risk, FX etc had used it at all. They're more interested in distributed computing and data grids than ORM. But anyway... talk about splitting hairs. Sorry ;) For my ha'penny's worth, I find that the amount of effort you need to put in to get a Hibernate-backed app working *right* is prohibitive. Some gripes: - Hibernate is like dry rot: it gets everywhere. You wind up having to code against it's nuances in all layers of an application. eg: + Accommodating the session in view pattern + beating the N+1 select problem + avoiding cartesian result sets + ridding the front-end of LazyInitializationExceptions + working around the issues introduced by proxying and lazy-loading - Finding a solution to your latest problem is non-trivial. Unlike Spring, with Hibernate you cannot just dip into it and use part of it: you need to be good at all of it or it blows goats. - Following on from that, Kudos to the dev team for creating such comprehensive documentation, building a Wiki and maintaining a FAQ. However, if I had a pound for every time I'd asked a question on the forum and been told quite arrogantly the answer was as plain as day in the manual, at section 10.2.15.339, I'd go to the pub for free beer all afternoon. The point is that there's just so much documentation to absorb before doing it *right* that it defeats the object. - The black-boxness of it all. What is Hibernate doing under the covers? Why did it just issue that update statement? WTF??? Ever tried debugging throught the source code? Not a pleasant experience. In-line comments? Who needs them? - Finding out that you still need to code your esoteric queries by hand in SQL. Don't get me wrong, Hibernate offers excellent benefits in certain situations. It's just horses for courses, like anything else. To my mind, relegating it to, say, customer registration where you're writing 30+ fields seems utterly demeaning to its creators, but that's where I'd leave it. I'll take the hit of using JDBC for more complex stuff before taking the hit of using Hibernate to do the same. Cheers Mike
  36. I would think it be pretty rare to find a kick-_ss developer who wasn't familiar with ORMs, and in particular Hibernate.


    Hi Michael,

    As a starter for ten, how about all the propeller heads who work in investment banking? I'd be quite surprised if those people working in risk, FX etc had used it at all. They're more interested in distributed computing and data grids than ORM. But anyway... talk about splitting hairs. Sorry ;)

    For my ha'penny's worth, I find that the amount of effort you need to put in to get a Hibernate-backed app working *right* is prohibitive. Some gripes:

    - Hibernate is like dry rot: it gets everywhere. You wind up having to code against it's nuances in all layers of an application. eg:
    + Accommodating the session in view pattern
    + beating the N+1 select problem
    + avoiding cartesian result sets
    + ridding the front-end of LazyInitializationExceptions
    + working around the issues introduced by proxying and lazy-loading

    - Finding a solution to your latest problem is non-trivial. Unlike Spring, with Hibernate you cannot just dip into it and use part of it: you need to be good at all of it or it blows goats.

    - Following on from that, Kudos to the dev team for creating such comprehensive documentation, building a Wiki and maintaining a FAQ. However, if I had a pound for every time I'd asked a question on the forum and been told quite arrogantly the answer was as plain as day in the manual, at section 10.2.15.339, I'd go to the pub for free beer all afternoon. The point is that there's just so much documentation to absorb before doing it *right* that it defeats the object.

    - The black-boxness of it all. What is Hibernate doing under the covers? Why did it just issue that update statement? WTF??? Ever tried debugging throught the source code? Not a pleasant experience. In-line comments? Who needs them?

    - Finding out that you still need to code your esoteric queries by hand in SQL.

    Don't get me wrong, Hibernate offers excellent benefits in certain situations. It's just horses for courses, like anything else. To my mind, relegating it to, say, customer registration where you're writing 30+ fields seems utterly demeaning to its creators, but that's where I'd leave it. I'll take the hit of using JDBC for more complex stuff before taking the hit of using Hibernate to do the same.

    Cheers

    Mike
    So, you must write everything you use? Just about everything is a blackbox..Windows, Java, pretty much any 3rd party library AND this isn't java only. C++ has the same issues in terms of 3rd party library. I don't have to understand exactly how Hibernate implements each and every feature provide that implementation does what I expect and most of the time it does. When it doesn't, well, that's why we get the bucks! I use the loading loading quite a bit and it has proven easy to work with provided: 1) You understand it (which is not to say *you* don't 2) You understand when and where to use it I would say that we've gotten some pretty good results with it. I would argue that it is very easy to pick up and run with it. Saying that and considering you mention Spring, it is easier with Spring than without. It is, IMO, easy, but Spring makes it even easier. In fact, when asked, I routinely recommended to people using both and despite the initial skepticism of "learning two frameworks" people have come to agree with me. I think it is a benefit that Hibernate, when necessary, allows you to use custom benefit. I would argue that it wouldn't be as popular without this Finally, would would say that I have been...less than entralled at times the forums, but heck, nothing's perfect! :-)
  37. I would think it be pretty rare to find a kick-_ss developer who wasn't familiar with ORMs, and in particular Hibernate.


    Hi Michael,

    As a starter for ten, how about all the propeller heads who work in investment banking? I'd be quite surprised if those people working in risk, FX etc had used it at all. They're more interested in distributed computing and data grids than ORM.
    John Davies offers a different opinion - http://www.theserverside.com/news/thread.tss?thread_id=42563
    Accommodating the session in view pattern
    Spring makes this trivial, although I prefer to do all my data access before the view layer
    beating the N+1 select problem
    Hibernate supports this well with runtime association fetching. in any case, N + 1 selects isn't specific to Hibernate or ORMs
    avoiding cartesian result sets
    again, not specific to hibernate
    ridding the front-end of LazyInitializationExceptions
    trivial if you're using OSIV, otherwise runtime association fetching is not very different than the dynamic sql most people are generating.
  38. I would think it be pretty rare to find a kick-_ss developer who wasn't familiar with ORMs, and in particular Hibernate.


    Hi Michael,

    As a starter for ten, how about all the propeller heads who work in investment banking? I'd be quite surprised if those people working in risk, FX etc had used it at all. They're more interested in distributed computing and data grids than ORM.


    John Davies offers a different opinion - http://www.theserverside.com/news/thread.tss?thread_id=42563

    I don't see where hibernate is mentioned here. Actually in the presentation it says something about not using databases at all. And as far as the kick-ass developer knowing ORM, I'd have to say that a kick-ass developer would know how to accomplish a task with or without ORM. A kick-ass developer (with a few years experience) knows that ORM is just another tool that may be supplanted by some other hot new thing in 5 or 10 years. The arguments that people are making about Hibernate as similar to those that were made about EJB a few years ago.
  39. ridding the front-end of LazyInitializationExceptions

    trivial if you're using OSIV, otherwise runtime association fetching is not very different than the dynamic sql most people are generating.
    Hi Michael, Thanks for the careful treatment of my reply, I was surprised people didn't go to town on it! It's been a while since I ran into the LazyInitializationExceptions but I was using the OSIV pattern, and I was using it with Spring, which as you say eases the set-up (although the meat of Hibernate lies in its domain mapping, not its factory configuration). I can't recall exactly what caused the LIE (great acronym) so it's better if we leave that point for now. In terms of generating efficient SQL loads, what I really missed when I used hibernate this time last year was the ability for the controller simply to pass an object-graph-descriptor through to my data layer, which would load the associated objects based on the extents of the descriptor and one or many root node ids. The criteria API comes close but describing the graph this way does not result in control over the load order. What I was after was something which would work out the most efficent order to load the different objects in, as some object types may appear more than once in the graph. With lazy-loading you would see sub-graphs loaded as you accessed the data, which is not necessarily the same as the most efficient way of reading the entire graph. This carries the benefit of being able to specify a simple loadGraph(Serialiable[] ids, GraphNode rootNode) method, so in each view controller you can then a specify the graph it knows it will need. This graph can be immutable, constructed statically and determine its query plan/load order at class initialisation. Now I'm just waiting for the avalanche of replies that say this is available and has been for ages... Cheers Mike
  40. I'm not sure I follow your argument. The people I work with with 20+ years experience with data modeling and application design are not 'good developers' because they haven't become acquainted with the upstart called Hibernate? I beg to differ.


    Sorry James, no disrespect meant there. You said, "SQL is probably one of the most commonly understood languages in the world. It's not 100% uniform but many people know it. More people know it than Java and vastly more people know it than HQL." I interpreted that as you basically saying that junior devs will probably know SQL, but may not know Hibernate. So basically SQL has the benefit that it's a lower common denominator, more people know it. The same way more people know html than Java. And really, it's not Hibernate per se, it's ORMs. And frankly, and again, I mean no disrespect here, but I would think it be pretty rare to find a kick-_ss developer who wasn't familiar with ORMs, and in particular Hibernate. Hibernate's really become rather ubiquitous in the last few years, so much so that the next f_cking implementation of EJB basically equals Hibernate.

    Every argument I've ever heard about Hibernate (until now) is that it makes things easier. Now you are telling me it's too advanced for the average developer?


    It does make things easier. The same way using a CNC machine makes cutting aluminum easier. Simplifying complex problems typically requires complex tools. But once usage of the tool is mastered solving that complex problem is much easier than if you didn't have access to that tool, don't you think?
    Not if the simpler tool solves the problem just as well. I always see these goofy rabbit wine-openers at parties. Frequently someone drives a cork into a wine bottle and splatters themselves and anyone near them with wine. I use a wine key. I can open a bottle in just a few seconds with it. I never push the cork through. It also fits nicely into drawer or a shirt-pocket and has a built-in foil cutter. You can use it to remove broken corks. The problem with tools like hibernate is that they are often only good at one thing. That's not necessarily a problem. It just seems to me that people want to use hibernate for everything. This seems no different to me than when everyone though they needed J2EE.


    Honestly, I think the main advantage of Hibernate is it makes it possible for developers that lack certain skills to succeed.


    I've seen this argument alot. Hibernate doesn't work well if you aren't well versed in SQL already. It's not a crutch for people who don't know SQL well, quite the contrary actually - you should only pick it up if you are already very comfortable with straight SQL.
    SQL isn't the kind of skill-set I am referring to. I am talking about a lack of OO design skills. Hibernate forces a certain design approach so a lot of decisions are already made. The approach it forces is OK, just a little mindless and verbose, IMO.


    Why do I need DAOs? This is where I start to get tired with the pro-Hibernate arguments. All the terrible advice in the J2EE design patterns is assumed to be 'the way' to do things. I am able to take my thin layer around JDBC and write a Java program that will write to and from arbitrary tables in around 100-200 lines of code (I wrote it with Jython which made it about 50 each for load and unload.)


    Um, ok. I quite like DAOs myself. In any case, say I don't create any DAOs, the code to persist *any* object graph, *of arbitrary depth*, is still one line. save(Object entity) if we do it your way saves any persistent class. Uh, how many lines did you say it took you?
    100, with no 'persistent classes'. How much code do you have in persistent classes? How much in XML configurations? I think you need to redo your math. Also, when someone needs to unload a table into a csv file, they just supply the name of the table. With your approach, they have to write a class and a mapping file.


    I guess what doesn't make sense for me with Hibernate is that it basically assumes that your Java classes are the 'real' model and the database is just some artifact of it. I see it pretty much the opposite. The database is real and the Java classes are are faint reflections of that data.


    The database is just data. The application (read, the Java classes) manages data AND logic. So no, in my Java code your database is NOT the representation I want to work with.
    Who says that you would? Why do you assume I don't have Objects to represent the data? There's no SQL in my business code. In the stuff I work on, the data is the most important thing. The apps exist to help people work with the data. It sounds like, to you, that the data is just there to support your application. Maybe it's just a different type of thing.



    But I think the whole approach doesn't make sense for the kind of application that I have been writing lately. I'm generally streaming data from the database, doing a little work on it and then writing it to output. Loading the data into beans has almost no value to me. In fact, it's constraining because now, I can modify some SQL and add data to the stream with no compilation. Writing a bean for everything is just a big waste of time for me.


    Sounds like your app doesn't have a complex domain model. No, Hibernate probably isn't so useful in that instance, nor any other ORM.
    I don't work on one application. our environment is much more complex than that. What a average domain model does in a single application, we are doing on a network level with many players, internal and external. A domain model that only applies to Java is too simplistic and doesn't solve a significant portion of the issues we face and is therefore a waste of time.
  41. The problem with tools like hibernate is that they are often only good at one thing. That's not necessarily a problem. It just seems to me that people want to use hibernate for everything. This seems no different to me than when everyone though they needed J2EE.
    How do you figure this? Perhaps the people who use it KNOW if they need it or not, certainly better than you would? You don't like it, understand it, or use it, fine, but why does that translate automatically into misuse by the people who use it. It seems to me that at best, the people around you don't know how to use it appropriately. I mean, how else can make such a claim. I would argue that the easier route is to use JDBC and the people who bother to use such a tool, especially when it isn't a standard, would have a better understanding of it appropriateness than the people who don't use it and cannot have as much experience with said tool.

  42. The problem with tools like hibernate is that they are often only good at one thing. That's not necessarily a problem. It just seems to me that people want to use hibernate for everything. This seems no different to me than when everyone though they needed J2EE.


    How do you figure this? Perhaps the people who use it KNOW if they need it or not, certainly better than you would?

    You don't like it, understand it, or use it, fine, but why does that translate automatically into misuse by the people who use it.
    I said "seems to me" which means it's only a claim about my perception. I'm not really sure what you are arguing. Are you saying you know better how things seem to me than I do? It's either a fact that this is the way it 'seems' to me or I am lying about how things seem to me. There's no way to prove or disprove how things seem to me so I don't think there's much point in arguing about it. Saying it 'seems' like something the case is not saying it is the case. If you want to understand me you need to understand that I attempt to be very precise with language on forums as we don't have benefit of face-to-face conversation. In any event, at my previous job it was being used because it was the new thing. It might have been a decent choice for some things but that wasn't why they were using it. They were building everything with custom SQL mappings.
    It seems to me that at best, the people around you don't know how to use it appropriately. I mean, how else can make such a claim.

    I would argue that the easier route is to use JDBC and the people who bother to use such a tool, especially when it isn't a standard, would have a better understanding of it appropriateness than the people who don't use it and cannot have as much experience with said tool.
    I've used hibernate. I think you are implying that I haven't or something. I don't think people should be writing a lot of JDBC code either. The problem is that I don't know of a good public API that simplifies JDBC for code that does very basic queries and updates. My best evidence of this is forums like this where hibernate is recommended for everything by a good number of people and when someone suggests it's not perfect for everything, they are told that they are just don't know enough. Kind of like your post here. Have you considered that perhaps I have vastly more experience in software than you? You don't really know, do you? You assume that you know better.
  43. Hibernate API: http://hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#objectstate-loading Java Persistence API: http://hibernate.org/hib_docs/entitymanager/reference/en/html/objectstate.html#d0e677
  44. I don't think this is the case with Hibernate 3+. "get()" will retrieve it from the session if the instance or it's proxy is present else a trip to DB, and will return null if it's not there at all. While the "load()" method will throw an exception (ObjectNotFoundException) if the object can't be found either in session or in DB. What the author said might have been the case with hibernate 2+ my 2 cents Vijay
  45. I don't think this is the case with Hibernate 3+. "get()" will retrieve it from the session if the instance or it's proxy is present else a trip to DB, and will return null if it's not there at all.
    Session.get() will always return a fully initialized instance, the guarantee is that the instance is fully available in any future detached state. This was actually aligned in Hibernate3 with the EntityManager.find() operation, which has been standardized that way. What you are describing is Hibernate2. Also see the documentation links I've posted... In practice it is nice to know that you might save a database roundtrip if you just use a proxy to create an association. But it should be looked at from a different perspective: - You use Session.get() or EntityManager.find() if you need the guarantee that the instance is fully initialized in both managed _and_ detached state (after the persistence context/Session is closed). - You use Session.load() or EntityManager.getReference() if you don't need that guarantee, which might save you a database roundtrip if you do nothing but create an association, with the proxied instance in managed state. The instance data is then not available fully in detached state. JPA implementations do not even have to implement getReference() in any other way than find(), however, Hibernate does. In other words, if you don't work with detached objects you can always use load() or getReference() and get the extra optimization of proxies in Hibernate. The names get() and load() are historical and we'd probably pick better names today for these methods (the JPA spec did). We discussed changing them in Hibernate3 but it was turned down in favor of easier migration from Hibernate2.
  46. Back to the original topic[ Go to top ]

    Christian said:
    Session.get() will always return a fully initialized instance, the guarantee is that the instance is fully available in any future detached state.
    This is not what the Hibernate Javadoc says: get(Class clazz, Serializable id) Return the persistent instance of the given entity class with the given identifier, or null if there is no such persistent instance. (If the instance, or a proxy for the instance, is already associated with the session, return that instance or proxy.) Does the Javadoc need updating?
  47. Re: Back to the original topic[ Go to top ]

    Check the Javadoc that comes with your version of Hibernate. The Javadoc wasn't updated until a recent Hibernate3 release, the one on the website might be a bit older.
  48. According to the Java Persistence with Hibernate book page 565: "The second call, getReference(), may return a proxy, but it doesn't have to - which translates to load() in Hibernate."
  49. getReference()[ Go to top ]

    With Hibernate as the provider, it may very well map directly to load(). I suppose whether it hits the database or not would depend on what provider you use and if/ how it supports caching. Does anyone one know if JPA providers are required to support caching?
  50. Thanks to Google Analytics. All of a sudden there was a spike in the number of visitors to my blog, and when i looked for the source, it was www.theserverside.com. I was clueless as to how that could happen? Dubiously, i browsed to serverside, and here i am, featured in the main page, and i didn't know! Honestly, this is an uncanny yet amazing experience. Thanks to "Joseph Ottinger" for posting it here.
  51. Oy! Can't have a thread on Hibernate without starting a flame-war on it. One case I found where a tool like Hibernate excelled over plain JDBC was with a query by example searching tool. I reduced a few hundred lines of code down to about 50 using the Hibernate criteria API. This didn't have a drop of HQL but was all Java. I can't think of a tool that would have made this simpler. There probably is another API floating out there somewhere but with Hibernate it worked great, was well documented online and in my Manning book, and only took a few hours to learn.
  52. Oy! Can't have a thread on Hibernate without starting a flame-war on it.
    Sorry. I shouldn't have started it. The author's fist sentence implies that people who question the value of Hibernate are just covering for their own incompetence.
  53. Oy! Can't have a thread on Hibernate without starting a flame-war on it.


    Sorry. I shouldn't have started it. The author's fist sentence implies that people who question the value of Hibernate are just covering for their own incompetence.
    Right - he lit the match from the beginning.