O/R Tool Hibernate 1.2 Released

Discussions

News: O/R Tool Hibernate 1.2 Released

  1. O/R Tool Hibernate 1.2 Released (51 messages)

    The Hibernate project has released version 1.2 of this popular Java O/R tool. Hibernate is an open source object/relational mapper designed to make persistence as invisible as possible to the business model. No special classes or interfaces are required, and the framework does not use bytecode compilation; instead, runtime reflection is used and SQL generation occurs at system startup time.

    The project is now one of the most active on SourceForge.

    Website:
    http://hibernate.sourceforge.net

    Feature List:
    http://hibernate.bluemars.net/4.html

    Forum:
    http://sourceforge.net/forum/forum.php?forum_id=128638.

    Threaded Messages (51)

  2. O/R Tool Hibernate 1.2 Released[ Go to top ]

    Exciting - Hibernate is starting to look real good!

    Is anybody using 1.2 or previous versions in any live scenarios. It would, especially, be interesting to hear about how Hibernate performs.

    On a more generic note..

    (While there are tools that provide a mix-and-match of the below approaches) There seem to be three dominant trends that seem to be poised for the long run in terms of transparent persistence in the J2EE world.

    1) CMP
    2) Proprietary O/R mapping tools (irrespective of whether they use runtime reflection or bytecode modification)
    3) JDO

    Other approaches like ODBMS aren't quite there yet.

    It would be interesting to know what percentage of people are using which approach. And what their experiences have been like.

    Personally, for me, CMP would have been the winner, if it had not been for entity bean overheads in the absence of application server caching.

    2) and 3) are similar in the sense that they both revolve around taking regular Java classes and mapping them to data stores. I separate them because 2) relies on vendor-specific technology and raises a host of concomittant issues issues about proprietary-ness.

    What do you think? Which one will "persist" longest? (pun intended and my apologies). Or will they all continue to co-exist for years to come?

    Sandeep.
  3. Changelog[ Go to top ]

    Here's a link to the Changelog in case anyone's curious about what's new in this version :

    http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/hibernate/Hibernate/changelog.txt?rev=HEAD

    changelog

    Brien Voorhees
  4. Hibernate & OJB[ Go to top ]

    Anyone used both (or seriously looked into both)? I'd appreciate a brief comparison of what you like/don't like as well as day-to-day development experiences, and overall which one you prefer.
  5. Hibernate & OJB[ Go to top ]

    Hi,

    I have played with OR tool such as EOF and others and have not found how they can save time. I admit to have little knowledge of these sorts of things, but based on what I have done and what I read, I just don't see it.

    A common theme that you hear is that the use of OR tools hides the 'ugly' SQL from the poor programmers. What is so hard about JDBC and SQL? And what makes me scratch my head is that these OR tools all seem to have there own query language that looks like crappy SQL! What's the deal? So unless you are doing simple database operations it seems that the OR tools need to drop down to SQL and /or SQL like syntax anyway.

    Beyond that I noticed speed issues, if you have a layer on top of the database it will be slower. So because of that problem they have caching. So with caching in place they got to deal with when to dump the cached data etc ... All the while the power in the relational database is lost...

    I don't have enough knowledge about OR tools to pronounce any conclusive judgment but this is what I see thus far. Any comments?

    Stef
  6. Hibernate & OJB[ Go to top ]

    Well I'm pretty sold on O/R mapping itself, I've used it on a large project and it saved us a ton of hassle writing mundane SQL code among other benefits.

    I was wondering more about specific experiences of anyone who's used Hibernate and OJB, and how they'd compare the two.
  7. Hibernate & OJB[ Go to top ]

    I use Hibernate with bottom down approach, and I know quite a lot about databases. What I like about Hibernate is it's flexibility. It really keeps all the aproaches (at least those what I think are reasonable) open. I use Hibernate's code generation tool and I think that it is awesome. It's nothing shiny or magic, but it does it's work very well. I do not use db schema generation tool (althought I could), because I like to write my schemas by hand.

    What is also great about Hibernate is that it is LGPL. And if you ever have to look at the code people (mainly by Gavin King) has written in this project, you will found it is quite a nice work. It's clean and easy to understand and even extend (even for me, :-)). What's more? You get lazy initialization with runtime proxy generation, very cool :-). I also like the ability to use JCS's JVM level caching (read-only for clustered environments and read-write for farmed or single server environments - you can use read-write JCS on clustered env., but it's not recommended AFAIK). JCS really makes a difference, I can say that.

    Stefan, you said that you see no value in OR enchanged SQL. I also have always hated idea of proprietary SQL extensions, but now when I have written some of this, what you say is crappy SQL, I really enjoy it (Look at Hibernate's SQL, it's not that crappy after all). If you want, you can always use direct JDBC style SQL with Hibernate. You have direct access to the JDBC objects like connection, resultset etc., whenever you need those (that's not often, believe me). You can even use direct JDBC even in the same transaction where you are manipulating Hibernate's OR-classes (pure serializable Java Beans). What about database support? Hibernate has very good support to many databases. I have used two: HSQLDB and PostgreSQL Server, but there is support for many others too.

    I mainly write database attached web applications and with good framework (like Maverick (truly view independed MVC framework - supporting both WebWork's approach and Strut's), or WebWork (not as clean or view independend as Maverick, but does it's work very fine), it is really a pleasure. I do not like much about these component oriented frameworks, e.g. Tapestry and WingS and Millstone, but YMMV.

    Also I'd like to say something about Hibernate's community. I have followed hibernate-devel mailing list for some time now, and I think that it's one of the best OS communities out there. Gavin manages this project with professional touch, but he is also very open to other people's opinions. I have only contributed twice, but the service has been great. I have not seen even one flame war or other silly fights, that I have seen on many OS communities I have followed.

    Stefan, you are also concerned about speed of these tools. Hibernate is quite efficient and in many times it even beats direct JDBC. But I'm not trying to convience you to use these tools (or hibernate) without thinking and profiling first what you are thrying to do and what are your requirements. These tools are not in any way silver bullets, but they are handy in many places. For me these tools work quite well. I have to use pure JDBC (or SQLJ or some other) only very rarely to optimiza some bottlenecks. Good tools like Hibernate don't go in my way when I need to do that.

    I really encourage people to try different tools to find out how they fit in. It takes some of your valuable time, but it can save some in the future. Some might argue that Hibernate is not viable solution as it's not "standards" based. Some might see it as an opporunity. I belong to the later ones. What I try to say is that, try to keep your mind open, but don't buy whatever shit people are trying to put on your hands, before you know what they are talking about.

    Is there something bad or some features that are not supported in Hibernate? Of course there is, there always will be. For example XDoclet integration has not been there very long (in fact I don't know about it's maturity). Also there is not very good support for dynamic schema updates (there is one tool, but I does not come with hibernate (and doesn't support all the databases hibernate supports), I think). Also I have found a small problem in Code Generation tool - it generates you Java code that doesn't compile, if you use reserved names like private, static etc. in mapping files. I have not reported about this, 'cause it's not a very big problem and can be corrected by adding character or two to make sure that it doesn't generate "bad code", :-). Also in general I see that by using these tools you could probably write inefficient code, if you don't watch what's happening beyond the scenes - that's not directly releted to tool. With hibernate you can enable, with one property setting (or you could use XML setup, if you like that, or even both), it to show all SQL that is going to database (or use some more flexible "profiling tool").

    Hibernate's configuration is easy and flexible. It works very well on multideveloper environment and gives you opportunity to use several mapping files instead of one central one - this discussion has been talked in for eg. struts mailing list, :-).

    This may sound you an advertisement, and it is :-). But I truly (as any good marketeer would say) talk only because I have personally tried it, and I use it in my own work too. I'm not connected to Gavin or anytone else in this project in any way, but I like to share some respect to these people as they have brought me a tool I really enjoy to work with.

    Thanks!


    Kind Regards
    Aapo <b/>ungle Laakkonen
  8. Hibernate & OJB[ Go to top ]

    bottom down approach


    cheers, and bottoms up :-))))).
  9. Hibernate & OJB[ Go to top ]

    I whole heartedly agree with Aapo. We've been productizing a CRM application written in house (that we used to replace Siebel) and are using Hibernate to allow us the freedom to easily deploy to any DB. CMP seemed too unwieldly for our needs and JDO simply isn't mature enough with a query language that is somewhat lacking. Hibernate is streamlining our code by removing an awful lot of SQL maintenance code and speeding along future development. For our team it has changed the way we develop applications removing the burden of writing all the SQL donkey work that has been a part of every application we have ever written. There is a learning curve with Hibernate and the documentation could use a full re-write but as Aapo said the community is great and Gavin is extremely helpful. Give it a shot, get something working and then make your decision I think you'll find it worthwhile.

    Damian Penney
  10. Hibernate & OJB[ Go to top ]

    <quote>What is so hard about JDBC and SQL?</quote>

    - catching all the checked exceptions from things you have no way of recovering from anyway
    - writing sql is error prone
    - writing sql is code duplication since many of the statements look exactly the same
    - using jdbc requires you to build in mappers, units of work, lazy loads, optimistic and pessimistic locks, identify maps to catch results and a whole slew of other things.
    - writing this kind of code usually involves several packages with several classes that coupled together. Change a few field name and have fun fixing more code than you would with hibernate or jdo
    - since all the jdbc operations are the same, you'll probably need to make frameworks and helper classes to simplify it.

    So, people who want to waste their time doing this - fine. Most people don't.
  11. Hibernate & OJB[ Go to top ]

    writing SQL is about as error-prone as writing Java (if you know what you're doing). Nobody keeps you from organizing your SQL (as you do with your Java) to avoid redundancies.

    Someone else said earlier that Hibernate sometimes was even faster than JDBC. Lets get things straight: whatever Hibernate does is eventually translated into JDBC calls. There is no way any JDBC-based framework can be faster than plain JDBC - given that any optimizations the framework can perform (like cacheing, minimal updates) can also be done by hand.

    Having said that, I do see a value in using an O/R framework. Sometime, my data needs to be wrapped into objects - and that may as well be done by a framework. I dont think one should ever expect much from the OO Query languages. None of them will ever realistically reach the power of SQL, and to really optimize the performance of your app, you WILL eventually have to delegate work to the DBMS (which usually does its job really good).

    Christian
  12. SQL and JDBC[ Go to top ]

    <quote>What is so hard about JDBC and SQL?</quote>

    The main problem is that JDBC is a poor API. SQL is a pretty good language for performing complex operations on relational data.

    O/R mapping isn't always helpful. In such cases, working with SQL can be the simplest thing, and can offer the best performance. I feel that too many J2EE developers believe that SQL is always evil.

    I strongly recommend that you check out the JDBC abstraction framework discussed in chapter 9 of my new book, Expert One-on-One J2EE. You can download the code from Wrox.com (although you'll also want to read the discussion in the book :-) It's a lightweight framework that gives you
    - unchecked, database-independent exception hierarchy with real meaning (such as DeadlockLoserException) instead of a SQL exception. There's no need to drill into SQL state or vendor codes. You only need to catch these exceptions if you want to, making application code much simpler.
    - No need to write finally blocks...connections are closed automatically, eliminating a common cause of errors
    - Designed to be used with the J2EE DAO pattern. Business objects don't need to know what persistence strategy is in use

    If you need sophisticated caching, sure, use a good O/R mapping framework. Hibernate sounds interesting. What I've described is basically a better JDBC. My book also devotes two chapters to choosing between persistence strategies. The sample chapter also briefly discusses the choice between O/R mapping and a SQL-based approach.

    Rod
  13. Hibernate vs. Others[ Go to top ]

    There seem to be plenty of Java<->DB frameworks and toolkits out there. Anyone seen a decent comparison of these?

    FWIW, I've used Castor's "JDO," it worked quite well and the learning curve wasn't too steep. I'd be interested to hear from someone who's used Castor, Hibernate, and Jakarta's OJB...

    cheers
    Pratik
  14. Hibernate vs. Others[ Go to top ]

    There _are_ lots of O/R mapping solutions. I guess this is one of the things that makes JDO so attractive--standardization on one API is promising. However, there don't seem to be many open source "better JDBCs", which is why I implemented one for my book.

    There's a comparison page on O/R mapping frameworks on C2 wiki, but it could do with more detail.

    Rod Johnson
  15. Hibernate vs. Others[ Go to top ]

    <quote>I've used Castor's "JDO"</quote>

    The main problem with this product is that it is not actually a JDO implementation. It actually uses the same OMDG standard as Hibernate but actually fails to implement it correctly in several areas. If you do a cross comparison with hibernate, I think you'll find that Hibernate is just better to use anyway.
  16. Hibernate vs. Others[ Go to top ]

    I've not used any of the OR mappers really extensively, but I have played with a few.

    In the long term, I might end up using JDO - I like a lot of things about it, but it's not very mature, and I had issues with several trials that I played with. Further, there aren't very many really free implementations. OJB's JDO support is not really there yet.

    I used EOF a long time ago when doing WebObjects. I liked it well enough, but I don't tend to use WebObjects, so the point's somewhat moot. It certainly whet my appetite for O/R mapping.

    OJB is nice enough, but the version I used was flaky in a few places, and the documentation could use a little work. It remained a candidate, but I wanted to try Hibernate as a point of comparison.

    Hibernate's documentation is still not perfect, but better than OJB's (IMO). The API is clear, clean, and usable. It supports aggregates, and non O/R-type queries, which I find to be handy. The support from Gavin and other forum members has been impeccable.

    As a result, I'm using Hibernate on a project now, and expect to make use of it on projects in the future. No hang-ups thus far, and I'm enjoying the experience.

    Only minor hiccup is that Hibernate and the Microsoft SQL Server JDBC driver don't get along that well - I'm using it, for the time being, but it won't pass the test suites, which is unfortunate. That's not a big deal for any projects of size, because most projects could easily afford the cost of a SQL server driver. For small projects, that may not be a factor because, despite the fact that it won't pass the test suites, it's working just fine for simple uses.

        - Geoffrey
  17. Hibernate vs. Others[ Go to top ]

    Geoffrey

    "Only minor hiccup is that Hibernate and the Microsoft SQL Server JDBC driver don't get along that well "

    Whats the issue with SQL server?.. I have been playing with SQL server and Hibernate for some time?.. Can u pls let me know the issue you faced?
  18. Hibernate vs. Others[ Go to top ]

    <pratheep>
    Whats the issue with SQL server?.. I have been playing with SQL server and Hibernate for some time?.. Can u pls let me know the issue you faced?
    </pratheep>

    Pratheep, what development configuration are you using? Are you using the MS JDBC driver for SQL Server 2k?

    Sandeep.

    PS: Personally, I think Hibernate is perhaps the best open source O/R mapping tool out there. What I like most about it is that its support for querying is excellent.
  19. Hibernate vs. Others[ Go to top ]

    I've used it with DB2 and SQL Server. Works great.
  20. Hibernate vs. Others[ Go to top ]

    I'm using SQLserver 2000 on a win2K machine using MS JDBC driver for SQL server from MS (originally from merant.).. I'm planning to use hibernate in a real project. I didnt have any issues.
  21. Hibernate and Microsoft SQL Server[ Go to top ]

    In answer to your question, from the FAQ (http://hibernate.bluemars.net/14.html) :

    Q: Why is Microsoft's own JDBC driver for SQL server not supported?

    A: The Hibernate test suite does not complete successfully using Microsoft's driver (even though most of the individual tests are successful). Some people are using Hibernate with the Microsoft driver but they do so at their own risk. Users of the Microsoft driver should not report problems without first verifying that the problem occurs with one of the recommended drivers. The standard test configuration is SQL Server 2000 + JSQL. An evaluation version of JSQL may be downloaded from http://www.j-netdirect.com


    Cheers,
    Brien Voorhees
  22. Hibernate vs. Others[ Go to top ]

    <quote>
    Only minor hiccup is that Hibernate and the Microsoft SQL Server JDBC driver don't get along that well - I'm using it, for the time being, but it won't pass the test suites, which is unfortunate
    </quote>

    Gavin, if you're monitoring this thread, could you perhaps give us some feedback on that. This was something I was planning to try out for some internal sites that use SQL Server.

    Sandeep.
  23. SQL and JDBC[ Go to top ]

    There's more to a good O/R mapping tool than just avoiding SQL, automatically closing connections, clean exception hierarchy, etc. A good DAO framework will give you those things, except for avoiding SQL - which you might not care about. But a good O/R tool will give you all those things and more.

    The bigger issues are the behavioral ones -- rememembering exactly what has changed, so you know what to insert, update or delete; making sure to avoid having two copies of the same persistent object (record) in memory; only loading data from the db when you need it. Believe me, these become big problems with a complicated app and a rich domain model. To solve these problems, you need the Unit Of Work, Identity Map, and Lazy Load patterns. The DAO pattern does not address these issues. For a good discussion of these issues, see the book 'Patterns of Enterprise Application Architecture' by Martin Fowler.

    Of course it depends on your app. If you complicated business logic and lots of tables, you'll want a rich, fine-grained domain object model, and a good O/R tool that implements these patterns will help a ton. If your app is mostly focused on presentation, and getting data in and out of the db, then the DAO pattern is good. Having said that, using Hibernate seems easier to use than DAO's, so I'd probably use it even for simple apps. It seems to make development quicker. It's probablly not good for dealing with stored procedures, etc. You can still use hand-coded JDBC with Hibernate to call stored procedures and gunk. But if your resource tier is all stored procedures and stuff like that, then there might not be much point to an O/R tool,

    Hibernate implements all of the patterns mentioned above. I've only been playing with it for a few weeks, but my initial tests show that it is as fast, in practice, as hand-coded JDBC. Development seems much quicker than writing your DAO's, even with a good framework. The API is clean. I like it.
  24. SQL and JDBC[ Go to top ]

    Rod Johnson:

    You should have provided the source for it since I don't like how you implemented various things (I guess I would have done a few things different). I wanted to create a lieght-weight wrapper like that for some applications, but I was looking forward to make one using your code. Now I'd have to do most of it by hand so I decided not to bother.
  25. SQL and JDBC[ Go to top ]

    Ken Egervari:

    He did. He posted a link to the book page, which features a large red button (to the right) which reads 'Download Code' :)
  26. SQL and JDBC[ Go to top ]

    Yes, the code is available from the Wrox site. If you have any problem downloading it, please post a message to the P2P list for the book (also on the Wrox site). Ken, if you want to share your ideas on how you would do things differently, please send me an email. The address is under "about the author" in the first few pages of the book.

    Rod
  27. SQL and JDBC[ Go to top ]

    <quote>Yes, the code is available from the Wrox site. If you have any problem downloading it, please post a message to the P2P list for the book (also on the Wrox site). Ken, if you want to share your ideas on how you would do things differently, please send me an email. The address is under "about the author" in the first few pages of the book. </quote>

    Thanks Rod. I will contain a list of design changes that I think would make it easier to use within the week hopefully. Refer to my comment above actually to explain my point about not having the actual code. Perhaps it was changed, but if I recall there were only jar files (that contained the class files only).

    As a side point, how was your experience with Wrox? Which office did you work with? I've actually co-authored 3 books with themself and was curious to see how a fellow author thought about it.

    Regards,
    Ken
  28. SQL and JDBC[ Go to top ]

    Yes I think they failed to include all the source code in the first download.

    I worked with the UK office of Wrox, with an editor I've previously worked with on a couple of books, and who's very capable. Overall, I was happy in that they gave me the freedom to express a sometimes controversial viewpoint (subject to a review process, of course, to ensure that it stood up to scrutiny, although of course some things are matters of opinion). I think the Expert series suited what I wanted to do. There are so many J2EE books out there, and so few that say anything genuinely new. Readers are free to disagree with my views, but I hope the book will encourage them to question some J2EE articles of faith that can prove hugely expensive. The forthcoming Bitter EJB should also provide some fresh commentary.

    I'm also in the process of setting up my own web site, which will offer a range of downloads, including the JDBC code. Also a bug reporting mechanism etc. Look forward to seeing your comments.

    Regards,
    Rod
  29. SQL and JDBC[ Go to top ]

    <quote>He did. He posted a link to the book page, which features a large red button (to the right) which reads 'Download Code' :) </quote>
    Oh, I just assumed it was the same one from the Wrox website. I downloaded the one at Wrox a week ago and it was only several jars containing the class files. I'll check to see if it's the same thing. If it isn't, he might want to get Wrox to update it.
  30. SQL and JDBC[ Go to top ]

    Rod,

    Just got your book and it kicks ass.

    Good stuff.

    Stef
  31. SQL and JDBC[ Go to top ]

    O/R tools are good providing pre-generation
    (or on-fly-reflection) of ~90% of sql code.
    There is always need for custom sql, so
    good OR-tools must provide clean way(s) to
    do it.

    Moreover [good] ORTool can provide transactions,
    caching, clastering (ie TopLink), controlled
    loading of dependant objects, batch
    optimization and, sometimes, offer generation
    of DTO, validation etc.

    Everywhere when strong datamodel (or legacy)
    meet strong OO domain model ORTools are GOOD.
    (btw EJB is also kind of ORtool).

    About stored procedures: In most cases
    domain business logic (DBL) and data itegrity
    logic (DIL) are different. DBL is mostly
    OO and better be implemented in OO language.
    DIL is not too OO (ACID, CRUD, PKFK) and can be
    implemented in database. [now I am reworking old
    application where there is no PKFK in Oracle!!!,
    but integrity is checked in pro*c and pl/sql code,
    also all DBL is in proc and plsql - brrrrrr]

    Thus, stored procedures for data integrity is
    fine, but for Domain logic is no good. Also,
    stored procedure requires separate development
    environment (skills, tools, source control,
    access rigths, DBA support, deployment path).

    And, of course, every project is different....

    AlexV.
  32. SQL and JDBC[ Go to top ]

    Alex, I agree completely regarding stored procedures. They should not be used to implement business logic, but they can be used to manipulate data (persistence logic) very efficiently in some applications, minimizing the complexity of Java code and minimizing expensive round trips to the database.

    As I argue in my book, the conventional J2EE view that stored procedures are always evil is misguided.

    Rod
  33. SQL and JDBC[ Go to top ]

    I don't know that it is J2EE wisdom as much as it is vendor neutrality wisdom. Java wisdom may be closer.

    I think that it is in response to "stored procs for everything". Store Procs are database specific. I only use them if performance is an issue. I usually try to solve that by moving the data access closer to the data. The only time I have HAD to use store procs was a tool issue with language conversion.
  34. SQL and JDBC[ Go to top ]

    Is "vendor neutrality" always wisdom though? I've seen obsession with it lead to inefficient, lowest common denominator database access in many applications...

    Sure, stored procs for everything are a Bad Thing. I've seen some horrible, scary applications in which stored procedures generate HTML etc. But the J2EE community seems to have jumped too far in the other direction.

    I think used correctly stored procs aren't a problem for portability anyway. Hide them behind DAOs. All you're dependent on then is having a target database that supports stored procedures (the language doesn't matter).

    If use of a stored proc is appropriate, the stored proc will be simpler than the Java code to do the same thing. So if you face having to port 200 line stored procedures to another RDBMS, you've misused stored procs.

    Regards, Rod
  35. SQL and JDBC[ Go to top ]

    If use of a stored proc is appropriate, the stored proc will be simpler than the Java code to do the same thing. So if you face having to port 200 line stored procedures to another RDBMS, you've misused stored procs. <

    Perhaps.

    On the other hand, the metadata required by an O/R mapper will be simpler than *either* the stored procedures (of which there will be a few per DAO) OR the Java code in the DAO class. It is certainly simpler than the two put together!

    And you get vendor independence pretty much for free.

    A further consideration is the fact that its difficult to find a single person simultaneously skilled in both the stored procedure dialect and Java. So changes in the data model require all kind of negotiation and lost productivity. (It doesn't take long for a Java developer to pick up the Hibernate mapping format!)

    Yes, its *possible* to implement stored procedures that will outperform the O/R mapper, but its *highly* unlikely that real developers will have time to do that for every class in a large system. On the other hand a good O/R mapper won't mind if you use some stored procedures for performance critical data access.

    Remember, if you can save time spent coding the 90% of the system which is *not* on the critical path, you will have *much* more time left over to optimize the remaining 10%.

    Given the tediousness of handcoding efficient data access (where associations are loaded with outerjoins, or lazily initialized) and given the fact that the OR mapper will do some things like PreparedStatement caching and JDBC Batching (that you may of may not have the time to implement yourself) it is highly likely a system built atop an efficient O/R mapper (with hand-optimized bottlenecks) will be both cheaper to develop and more performant than a system built directly atop JDBC.

    Of course, a lot depends upon the complexity or your data/object models and upon wether they need to change (ever).
  36. SQL and JDBC[ Go to top ]

    <q>
    A further consideration is the fact that its difficult to find a single person simultaneously skilled in both the stored procedure dialect and Java. So changes in the data model require all kind of negotiation and lost productivity.
    </q>

    I don't think the stored procedure developer need to know anything about java, what (s)he concerns about is user requirement, domain model or database structure. Neither does a java programmer need to know procedure language, (s)he only needs to understand interface rather than implementation detail.

    <q>
    Yes, its *possible* to implement stored procedures that will outperform the O/R mapper, but its *highly* unlikely that real developers will have time to do that for every class in a large system. On the other hand a good O/R mapper won't mind if you use some stored procedures for performance critical data access.
    </q>

    As to relation data access,why do you need to create class at all? Let's inspect all posible DB interaction cases:

    1. For display only( as most jsp do, no matter it shows a form or html table). The main reason I'm against on passing object to presentation layer is it will leads to tight coupling between presentation layer and business layer. The UI components has to know what fields or methods the entity object has, and how to get them. If you write a jsp to display a HTML table of Order, you are binding them at compile time, any change on interface Order will affect your jsp. And you can't reuse your jsp to display a Employee table, although the only difference is name of fields to display(You can use reflection after all, but that's both ineffecient and error prone). In our project, we use some similar method to declare meta data as hibernate or other O/R tools do, but our framework just create *PURE DATA*, that is, HashMap for entity, Collection for a list of entity, Collection of Collection for composite or tree structure. You don't need to write interface for every table, you just declare what fields you need, then you get your data. Order is a Map, Employee is a Map, everything is a Map. So you can have a runtime binding between presentation layer and business layer, the two layers are loose coupled. You can have a reusable HTML table component, which accepts a Collection of Map for model, and a Collection of Map for table column properties( field name, width, align, font etc), it can display any entity. Another benefit is you can chain data processors before them get to upper layer, so you can enforce access rules, format text, transform data structure( from plain list to tree, for example), cache data etc - as long as all processors accept pure data container as parameter. That's much more flexible than O/R mapping, you can even change or create meta data at runtime and get your data transparently. If you use O/R mapping, can you add a field or change field type without re-compiling?

    2. For update. I don't see the value of loading data into java class, changing its content and then write back to database. Why we need the middle level object? Let's face the fact, SQL has already provided an abstract layer for relation data, so we just need to construct SQL statement and pass parameters to them. If the update action is as simple as CRUI, you just declare which entity and what fields to update, and let framework to create SQL - same as O/R mapping tools do, but you don't have to create an object instance to make update. Why not just use a HashMap, a Collection of HashMap, or any data container from java.util to pass parameters? If the update action is complex, just write a stored procedure and pass parameters to it. Why do you code like

    Collection orders = customer.getPendingOrders();
    Iterator it = orders.iterator();
    while( it.hasNext()){
      Order order = (Order)it.next();
      if( order.getTotalSum() >= 50000){
         order.setStatus( xxx )
      }
    }

    if you can simply

    update orders set status = xxx
    where OM_total_sum(order_id)>50000
    and OM_is_pending_order(order_id) = true

    ?

    3. For consume, where you get data from database, and do certain work that is not DB related, such as send hardware instruction or write something to disk file. That's the right place for O/R mapping, but even in this case, we can still use pure data container to get many works done.IMHO, for most projects we don't need entity objects at all. Just treat data as data.
  37. SQL and JDBC[ Go to top ]

    Fan Zhou,

    BC4J framework by Oracle is similar to
    what you have described - mostly works
    with generac containers in presentational
    layer. Nevertheless in domain level
    objects are better than hashtables,
    and better than direct database
    manipulation.

    AlexV.
  38. SQL and JDBC[ Go to top ]

    I tend to agree with the Fan. While strongly typed domain objects are good for business logic, there is not so much of real business logic in most of the (web) applications. 95% of the logic is formatting, validating and converting data that is hardly _business_ logic and preferably should be parametrised. Real business logic is something like "Total order line value must be more then $250 for products of type 'bulk'".

    Alex,
    I have used BC4J in early 2000 and it was very bad then, basically Oracle was marketting product that was not ready yet. Some of my gray hair can directly correlated with use of BC4J ;-(. Still I would very much appreciate your comments if it had improved since then, even better if there are other similar frameworks available (OS?), since I swore not to use BC4J stuff again.

    Coming back to the need for strongly typed domain objects, and the fact that there are mostly used for formatting/validation. The data convertion and formatting functionality was comming right of the box in most of the C/S tools in the 90-ties (Oracle Forms etc.). Seems to me that since then we have made a step back.

    To my big frustration most of the project I've joined were so bogged down in formatting, validation and coping the dat between n+1 layers, that there no budget left for doing actual business logic and users had to settle for pretty unintelligent system.

    In one exteme case data was copied: JSP <-> servlet <-> Value Object <-> EJB <-> JDBC <-> stored procedure <-> actual SQL. 1000s lines of code, at the same time there was so little business logic in the application that ca. 1997 it could have been autogenerated from Case tool.

    My 5 cents go to keep it simple: rule of the thumb start with no stored procedures, no EJBs, and limited use of strongly typed objects.

    Michael
    http://ITSolv.ca
  39. SQL and JDBC[ Go to top ]

    <Q>
    Just treat data as data.
    </Q>
    That is the problem. Seldom is data just data. There is at the very least descriptors to the data.
  40. SQL and JDBC[ Go to top ]

    <q>
    IMHO, for most projects we don't need entity objects at all. Just treat data as data.
    </q>
    Fan Zhou,
    where you do all the validations, calculations etc.
    In JSP or in database?
    I haven't see application yet where data can be just displayed or just stored as is all the time.
  41. SQL and JDBC[ Go to top ]

    <q>
    where you do all the validations, calculations etc.
    In JSP or in database?
    I haven't see application yet where data can be just displayed or just stored as is all the time.
    </q>

    In my projects, before the data gets to database, a list of processors will take effect, each doing a simple, specific work. For example, when the customer submits an order, first a HashMap will be created by parameter parser which takes ServletRequest and parameter configuration meta data as input, it will check common validation rules such as whether a field is null or is of required data type. When it finishes, the Map will contain valid parameters for this usecase. Then a quota checker makes sure total price of the order is below the customer's limit, if it passed, a discount calculator reads discount config and get total discount of the order, save calculation result in parameter Map. Finally the parameter Map will be passed to a list of pre-defined SQL operation, simple insert statement or stored procedure. The whole process is totally configurable, dynamic, at runtime, even by end user.

    Since the processors all operate on pure data container, they are loosely coupled and many processors can be reused. If in another usecase you need to enforce some validation check, you don't have to write "if( xx == null) throw new DataInvalidException()" in 20 setters, you just declare validation rules and let the parameter parser to do so.If you use an entity object, you get all these cross cutting features in one big class, which is costly to develop and maintain.
  42. Hibernate & OJB[ Go to top ]

    Stefan,

    I completely agree with you. I never understood the big deal with O/R mapping tools. I have looked at few, but never felt the need. Moreover, there will always be the weired use case and you have to to resort to SQL tricks anyway. I just use a wrapper around JDBC and externalize all SQL queries as java properties.

    I would lot more interested in an open source solution for cluster aware cache, with configurable cache parameters.

    Pranab
  43. Hibernate & OJB[ Go to top ]

    I am a four-year java player and work as system engineer for BEA. In the past years, I saw many projects used the wrong JDBC codes that caused the whole project failed. It is true that JDBC is easy to learn. But there are new comers in Software company every years, includng project managers. And they may have no time to learn the technical details but spend more time in keeping on schedule . (Though it is nightmare, but it is real,especially in small company).

    OR mapping provides a persistence layer to separate the java objects from the data in db. To a developer , what he sees are all java objects , not care the persistence logic. This means the developers needn't learn JDBC, even needn't learn Database. So they won't make mistakes like the above.

    I think OR mapping is very useful in software engineering .
  44. Hibernate & OJB[ Go to top ]

    Everywhere I see people say that stored procedure is evil, and you should put business logic in objects. So what's wrong with stored procedure? AFAIK O/R mapping fans have the following options on sp:

    1. It's not vendor independent
    2. I don't want to learn a new language besides java
    3. It doesn't scale
    4. It's not object oriented,
    5. It's hard to maintain

    As for 1, that's true, but as long as your project is not very very large and doesn't require surpport for more than one databases, I think thin client (JSP/Applet/Swing) + stored procedure is a good solution. If you think this is obsolete and not so cool, then just take a look at Oracle applications 11i, its ERP product is sp backended. Are there really many projects larger than Oracle ERP, which has 100,000+ tables ?

    The other points IMHO are inaccurate:

    2. I think the architecturer should always make a clean seperation between ui and business logic, thus those who write screens or forms should never touch implementation detail of stored procedure,all they need to know is interface, i.e. what method should be called, and what parameters should be supplied. Is it any different with EJB method call?

    3. Most major RDMBS products are scalable( Oracle, MS SQL, DB2, etc) but, anyhow, just look at today's tpc results, I don't think most projects require 32+ CPUs to work.

    4. Well, I think what we are doing is nothing but construct software to solve some real world problems, and the ultimate objective of OO is nothing but reduce software development and maintain cost. As long as you can finish your project in acceptable time and resource, why do you need to use OO all the way? Most OO features can be implemented in SQL world. You can make various views for business entity, encapsulate business logic in procedures, make calling interface public to upper layer, while hide implementation details. When your data structure change, as long as the interface( view fields, parameter declare of procedure) remains consistant, you need only change implementation( SQL of view, procedure body). You can make your business method polymorphic by saving procedure names in table and use dynamic sql to perform procedure call at runtime, depending on different data you operate on. That's the same as you subclass a abstract class and override some methods, then pass it as parameter to other instance that accepts its parent class type. That really depends on some vendor specific extenstion to SQL92 but believe me, SQL is by far more expressive and effecient than java for relation data.

    5. I don't think maintainability has anything to do with language. I'v seen system with over 100,000 lines of SQL code that runs very well, and I'v also seen many projects that use EJB failed at all. The most important factor that affects maintainability is complexity. People always fight complexity by dividing complex problem into simple ones, big module into small ones, make clear documentation, clean seperation and good organization of different modules/layers/code parts. Java(or other OO language)is just one of the many possible solutions, but it's not necessary the best one.

    I don't mean O/R mapping is not good, obviously there are cases where you need to get an object representation of relation data, but most time SQL should be a better way to interact with RDBMS.
  45. Hibernate & OJB[ Go to top ]

    Yes, I think the OR mapping is not suitable for every project, it depends on the details of the project,just like the ejb , ejb cann't do everything, neither the OR mapping. A new technology comes , it always brings some experiences to make things simple, but is it the key to your door? Maybe , maybe not
  46. O/R Tool Hibernate 1.2 Released[ Go to top ]

    The documentation for Hibernate is very good, but O/R mapping is a complex subject, dealing with issues such as caching, transactions, performance and working with legacy systems. I would be more than happy to shell out 50 bucks for a comprehensive and example filled book about Hibernate.
  47. O/R Tool Hibernate 1.2 Released[ Go to top ]

    Interesting point. O/R mapping tools are critical to the success of projects using them, yet people don't seem to be prepared to pay for them (or the documentation) in the same way as they're prepared to pay for app servers. And so far there hasn't been a JBoss-quality open source O/R mapping solution (if there is, please correct me!)

    Rod
  48. O/R Tool Hibernate 1.2 Released[ Go to top ]

    As it stands, Hibernate is the *best* open source o/r framework available. I've looked into many (and even designed a few myself in other languages) and I would have to say Hibernate scores very high in the open source world. As for how it scales in really large applications, I'm not sure. Someone else with more experience with the tool would be better suited to answer the 'scalability' question. I think since it's built on JDBC, it's probably a scalable if not more than JDBC itself. It's not a very heavy framework afterall.
  49. O/R Tool Hibernate 1.2 Released[ Go to top ]

    Apologies for deviating from the main topic, but this seemed a good place to comment/ask:

    Coming from a RDBMS background, I think O/R is quite a pain, and am experimenting with keeping everything "live" in Java and batch exporting to DB for legacy reporting and analysis only.

    Are others here experimenting with Prevayler ( www.prevayler.org ) for object persistence?

    What do people think about connecting to the traditional RDBMS as a legacy "app" only, and trying to keep all data storage / operations in the Java object context?

    TIA
    j f
  50. O/R Tool Hibernate 1.2 Released[ Go to top ]

    I have the following question.
    Is there any some sort of BMP O/R mapper?
    I want to map a relational model in which different classes should be mapped from the same table. Something like

    Table Object (id INTEGER, type INTEGER, name VARCHAR)
    Table Attributes (id INTEGER, attribute_name VARCHAR, attribute_value VARCHAR)

    All objects have something in common (so there would be a base abstract class or interface) and the "type" field indicates the concrete implementation class.
    The possible attribute_names in table Attributes change depending on the type.
    Is it possible to map this schema with one of the O/R mappers?
    With BMP Entity Beans it is possible, but I would like to use a solution that avoids the BMP N+1 problem.

    OTOH, I think CMP Entity Beans are very limited because they are only useful with local interfaces, which is not a problem for some applications, but if I want to make a generic object model for use in different applications (different EARs, that is) i get a lot of ClassCastExceptions because of classloading problems.
    BTW, those who say that the distributed object capability of EJBs is a disadvantage are just ignorant. Every one knows that any good EJB server implementation would optimize the calls if they are in the same virtual machine. In fact, I think CMP EJBs have serious disadvantages because they are useless with remote interfaces, so they can only be used with local interfaces within a single EJB application. Local interfaces are a big mistake, I think. It should have been left to implementors to optimize intra VM calls.
  51. O/R Tool Hibernate 1.2 Released[ Go to top ]

    Is there any some sort of BMP O/R mapper?


    There is. Hibernate. :-)
  52. O/R Tool Hibernate 1.2 Released[ Go to top ]

    Is there any some sort of BMP O/R mapper?


    Yes, CocoBase is a general O/R mapping tool, and has code templates for generating BMPs for most of the popular app servers automatically. You can start from an existing java object model, an existing RDBMS model, or UML model and create BMP EJBs with O/R mapping used. It also tends to run significantly faster than JDBC BMPs because of the design and coding patterns and optimizations used - which tend to much harder to replicate and reproduce with JDBC alone.

    And it is a general O/R mapping layer that provides the only portable CMP solution with advanced O/R mapping including Dependent object support (not due out for potentially several future releases of the EJB Spec!), and it supports EJBQL for BMP, CMP and standalone java applications without an EJB server.

    And lets not forget, that it typically performs as fast or faster than JDBC (many of our performance tests show CocoBase running as much as twice as fast has hand coded jdbc for most operations - and that's without caching enabled!). Compare that to the typical 'free' solution which runs on average twice as slow as JDBC and you can see why it's worth paying for a commercial product in this area instead of using a free one...

    Oh, and much of CocoBase shared source, including our Transparent Persistence APIs which are the only ones that work transparently inside and outside of a J2EE container (we use a session bean for the generic remote implementation). The code generation templates are shipped as an extensible system. The runtime has full plugin and developer override. Unlike most systems (including the Open Source ones), CocoBase was DESIGNED for user extensibility. It's based on a framework methodology with easy to use extension APIs - very critical for complex enterprise projects, not just prototyping.

    CocoBase was the first Java O/R mapping layer, and integrates with more databases, platforms, ides, modeling tools, etc. than any other O/R mapping product or project. If you're even considering O/R mapping, you should have a look at the tool that most others spring from in the java world - even if their creators are unaware of where the original concepts they use in their clones originated from...

    Just my $.02

    Ward Mullins
    CTO
    THOUGHT Inc.
    http://www.thoughtinc.com