Slashdot Mirror

May be you (and your co-worker) should take a look at Hibernate In my company, we are using something similar (well, same concept, just another implementation with less feature -don't shoot at me, i'm not to blame for that-) and the whole stuff performs quite well (so hibernate should perform even better, heh ;-) )

Ok, here are a few reasons why I *wouldn't* want to use that hibernate syntax:


It's been a year or so since I last used Hibernate, but IMHO, it rocks compared to hand-written SQL. Now, for your points:


1. how do I separately validate the syntax & query results? Can I run it in on a command-line? In a query tool, etc?


There exists a GUI tool for this, see http://www.hibernate.org/259.html


2. how do I diagnose subtle problems caused by hibernate join failures? Exactly what sql is it running?


You turn on the sql output switch in the config file, and look at the sql which depending on your configuration is output to the console or the log file.


3. how much flexibility does it have?


A lot. :-)


Can it handle outer joins?


Yes.


Subselects?


Yes.


Group bys?


Yes.


Aggregate functions?


Hmm, I don't remember, but I suspect not. Of course it is possible and advisable to use both SQL and Hibernate in the same application.


4. How do you leverage dbms-specific features? Yes, I know that it's best to stay generic, but when you need to add more analytical queries to your app (to deliver something beyond simple CRUD), you want to use olap functions, etc. Now, yeah, you could do this in your app. But it'll be slower. *Far* slower: you might have to process a hundred thousand rows - and the database will do it in less than a second. Your app? Maybe 5-10 seconds?


In general, Hibernate has pretty good support for stuff that you can find in standard SQL. Also, the architecture of Hibernate makes it extremely suitable for CRUD style stuff, e.g. the caching works very well if the app has any notion of working set, and Hibernate saves huge amounts of time when retrieving complicated object graphs compared to writing SQL by hand. For reporting, OLAP etc. Hibernate is less well suited. The general consensus seems to be to take advantage of Hibernate for CRUD stuff and do complicated reporting/OLAP/whatever in (vendor specific) SQL.


My recommendation is to learn sql, use standard sql whenever possible for portability. But learn the advanced sql required to deliver robust functionality. And when required be prepared to dip into vendor extensions.


My recommendation to you is to at least take a look at Hibernate; it makes you look less like a fool when people see that you have at least a vague idea of what you're talking about. ;-)


Or stay away from huge, challenging, and powerful business applications.


Yeah, that's what I do these days, business apps tend to be very boring. Fortran (and computational physics) forever!

They definitely expect other apps to be using the database at the same time; see, for example, a few of the entries on the Features page and some discussion in the second-level cache section of the manual.

They definitely expect other apps to be using the database at the same time; see, for example, a few of the entries on the Features page and some discussion in the second-level cache section of the manual.

I don't trust/want something to auto generate my sql tables and such based on my objects. That leads to problems, since the queries can't be tuned or maybe you don't get what you expect. So, i am using SqlMaps.

Perhaps you should try actually using Hibernate.

First, Hibernate works just fine with hand-generated SQL tables. Indeed, that's the only thing I've ever used it for. Second, you can happily tune your queries through hinting to Hibernate and careful choices of object relationshiops, and the recently released Hibernate 3 allows to you hand-write all the SQL if you choose.

Third, you're kinda missing the point of Hibernate. Using Hibernate akin to using Java itself in that both of them hide a lot of details about the underlying operations so that the programmer can spend their time and energy focusing on the essential problems rather than the details of the technology.

Most programmers doing SQL stuff in Java let the weirdness of SQL databases distort their designs heavily. They don't really do OO programming because they spend all their time thinking about database operations. Hibernate lets you do good OO design and have 95% of the SQL rituals handled under the hood.

It's possible that you lose some performance to Hibernate, although I never noticed it, and Hibernate's built-in caching means that many apps will be faster. But really, if performance is all that important to you, you shouldn't be using a database at all. Serializing all your data every time you need to work with it is incredibly expensive. There's a reason that things like Google and Quake aren't built on top of SQL databases.

I don't trust/want something to auto generate my sql tables and such based on my objects. That leads to problems, since the queries can't be tuned or maybe you don't get what you expect. So, i am using SqlMaps.

Perhaps you should try actually using Hibernate.

First, Hibernate works just fine with hand-generated SQL tables. Indeed, that's the only thing I've ever used it for. Second, you can happily tune your queries through hinting to Hibernate and careful choices of object relationshiops, and the recently released Hibernate 3 allows to you hand-write all the SQL if you choose.

Third, you're kinda missing the point of Hibernate. Using Hibernate akin to using Java itself in that both of them hide a lot of details about the underlying operations so that the programmer can spend their time and energy focusing on the essential problems rather than the details of the technology.

Most programmers doing SQL stuff in Java let the weirdness of SQL databases distort their designs heavily. They don't really do OO programming because they spend all their time thinking about database operations. Hibernate lets you do good OO design and have 95% of the SQL rituals handled under the hood.

It's possible that you lose some performance to Hibernate, although I never noticed it, and Hibernate's built-in caching means that many apps will be faster. But really, if performance is all that important to you, you shouldn't be using a database at all. Serializing all your data every time you need to work with it is incredibly expensive. There's a reason that things like Google and Quake aren't built on top of SQL databases.

I think most projects have both. I'm currently using hibernate which has both an API reference and a 'reference guide', which I find a bit lacking here and there (I wouldn't have called it a reference guide) but it does the job.

Recent examples include things like displaytag library, Hibernate and HTML Area.

Of course, this means I must take a wide berth around GPL'd code, but there is enough stuff under BSD/Apache/whatever to get the job done.

Hrm...I thought you meant that you were copying-and-pasting code. In my experience, abused like crazy in scripting.

But you meant you were copy-pasting URLs to find PHP libraries?

BTW -

generating PDF's
http://www.lowagie.com/iText/

dynamic graphics
http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec. html

menus
huh? If you have a cms like http://opencms.org/, which you should use anyway - you got menus.

DB interfaces
http://hibernate.org/

Woah. Now what dows OR-Mapping have to do with the question? Nothing, right? Any good workflow language or workflow API will be independent from storage. Besides I found working with Cayenne much more painful than working with Hibernate and Naked Objects promises lots of things nobody really wants. But this is not the scope of this "Ask Slashdot".

Seems to me Hibernate is the closest there is in that field. IIRC its lead is now working on EJB3 specs. It's a Jboss project, and I've used it with Tomcat without problems.

First of all don't use EJB's unless you have to. If you don't need distributed transactions then stay away. You don't want heavy weight frameworks to drag you down. Read: Better, Faster, Lighter Java. http://www.oreilly.com/catalog/bfljava/ For a free introduction read: http://www.onjava.com/lpt/a/4744

My personal advice is a stack made of:

1. JSF for the webfront. Struts if you are a bit more conservative. http://struts.apache.org/
2. Spring for the business logic. http://www.springframework.org/
3. Hibernate for persistence. http://www.hibernate.org/

Don't forget to have fun.

• Hibernate for object relational mapping and cross compatibility with most major databases (ie, develop on MySQL, deploy on Oracle, Informix, whatever you want).
• Spring which manages your mappings and helps maintain consistency across your data connections and helps you abstract your business logic, keeping it out of the actual pages. It also integrates with . . .
• Struts which gives you a great Model-View-Controller framework to practice good development and good security.

Interesting, this is the first post I could find that mentions any framework libraries. Does everyone here just use straight JSP?

I would be interested in /.er's opinions on framework libraries such as struts and hibernate.

Yeah - take a look at Hibernate. There ya go... high quality, free, object persistence for Java that works with most all major relational databases.

The good news: Apache Geronimon. Free, documented. 'nuff said.

More good news: Spring framework, Hibernate, iBatis..

Who needs EJB when there's Hibernate http://www.hibernate.org/ and Spring http://www.springframework.org/. Persistence, Transaction Management, and SQL generation in one tidy package. And it works on any J2EE app server, no matter how lightweight or robust.

Not that I have qualms with any attempt to provide these services in PHP. It's not a matter of having just one tool in your toolbox, but rather knowing which tool is right for which job. My only response to the original poster is "I don't want to start a flamewar, but if you aren't a sound enough engineer to know when to use which tool, you pretty much suck."

This month's meeting at my local Java user's group there was an impressive demo on Ruby on Rails. The presenter built a blogging application live in front of the group, literally in 10 minutes or so. Prior to this demo I had pretty much written Ruby off "just another alternative to perl or python" but I have to say that Rails looks really impressive, enough so that I'm taking a closer look at Ruby.

One of the guys in our user's group, Chris Nelson, is building a similar framework for Java - called Trails. He also built a blogging application live during the meeting. It took him a bit longer - perhaps 15-20 minutes. It was impressive as well, although I will say that for Trails you need to know a fair amount about Hibernate and Tapestry. Realize that he's been working on this only for a few months and suddenly you see that this work is very impressive too.

Anyone interested in developing web apps might want to check these projects out - very impressive stuff!

You do realise that J2EE is not a synonym for EJB don't you? And that xdoclet is one of the worst villains when it comes to meta-data hell?

Do yourself a favour, stick with J2EE, dump that p-o-s EJB and use Hibernate and Spring and you'll do fine: and be amazed how much you can achieve if you don't tie yourself to the EJB dead horse. Seriously: you'll thank me.

The relational model supports any kind of data structure ever invented, but it's true that you sometimes want to store opaque blobs of data such as graphics or XML documents, and most databases, including Derby, supports that as well.

Perhaps you should look at an object-relational mapping layer such as Hibernate or TJDO, or a hybrid object database such as Prevayler.

Talking SQL nowadays strikes me as being like talking raw assembler. You can do it, the tools are even rather nice nowadays, but any sane developer would use a higher level wrapper.

Like for instance, Hibernate. It does serialize/reconstitute, handles nested objects and data structures, and it's very nearly as easy as programming with regular heap-allocated objects. In any big app if you didn't use some such, you'd end up reimplementing it.

I see no reason wrappers like Hibernate have to backend onto SQL and only SQL. They could as easily emit and control this "Tutorial D" language.

Now that's quite interesting..

I double checked the current hibernate docs and there is no way to mark an object for deletion.

Specifically look here

p.getChildren().remove(c);
will not remove c from the database; it will ony remove the link to p (and cause a NOT NULL constraint violation, in this case). You need to explicitly delete() the Child.
Of course delete() is what actually deletes from the database.

In the applications I usually write the user can do many things to the set of objects (multiple page round trips) and want them committed only when they hit that final save.

And here is the kind of sequencing, parent<->child linking problem I have.

Page->Group->TechSpec
->Products->TechSpecData
Additionally there is a link between TechSpec and TechSpecData.

The deletes have to go TechSpecData, Products, TechSpec, Group, Page.
The inserts have to go Page, Group, TechSpec, Products, TechSpecData.

And of course the key from TechSpec has to cascade to the referencing TechSpecData.

Even if you ignore the fact you can't mark an object for deletion.. I can find no reference to controlling the order of the operations of children if you call saveOrUpdate.

In the persistence layer I use I can mark groups for deletion, modify the page and other groups. And then with a single Page.save() get everything deleted, inserted, and updated.

Under hibernate I found I had to use the essentially the same code to track and sequence things properly.

But since all of these things were done by Hibernate for you..
Just how do I mark an object for deletion during the saveOrUpdate?
How do I specify the order of operation for the delete/insert/updates?

Inquiring minds want to know.

-Jerry

Usually, problems with mapping existing database schemas to Hibernate arise from the shorcomings of the database and not Hibernate. Oracle's CLOBs and BLOBs are a good example of this, as the methods exposed by the JDBC interface do not work properly and methods from Oracle's CLOB and BLOB classes must be used directly, breaking transparency and forcing the developer to do additional work.

i.

Would it be too much to tell us what Hibernate acutally is/does?

Have all you people asking this been living under a rock??!?? It's an ORM (Object-Relational Mapping) tool for Java. Would it kill you to actually click a link?

• ...program names are getting more pointless by the day (Hibernate?), and...
• ...how most programs are mostly hype (more buzzwords than a Dilbert book).

Hibernate is a persistence layer for POJOs (plain old Java objects). Basically a way to map objects to an RDBMS, and manage transactional persistence. See http://www.hibernate.org/ for more information.

> Its' not the case in Java where it sounds like there's only 1 way to do each thing

I take it from this comment that you haven't actually tried java. You can "explorate" to your hearts content, and there are many ways of doing the same thing (some obviously better than others)

> mostly because of the plethora of APIs (WebLogic, etc.) that corporations force you to use over it...

Now this comment just has me bamboozled... You mean that Weblogic holds sway over you and force you to code in one way over another? Surely weblogic is just an appserver? Which runs code designed to the standard J2EE API spec? The same as using Tomcat , JBoss or Geronimo or even Hibernate? (All of which are free and opensource, and follow the same J2EE spec that Weblogic does -- they just solve separate parts of it, and can be combined to do it all if you require)... I fail to see how this is a corporation forcing you to use one method of coding?

Sure, if you are only going to look at one way of achieving your goals, then there is only one way to go...

Sorta seems like the same thing to me.

You should be happy using servlets and jsp

Um, no thanks. JSP sucks. Having code in the UI layer is a big no-no. JSP's are hard to maintain. I agree with you that J2EE persistence with EJB's sucks, but you can certainly do a lot better than jsp and servlets.

Check out Tapestry, a much better way to write web apps than JSP, using MVC so that your html page is just an html with certain id's on some tags, and you have components that can be placed inside other components to make up a page. Or use Struts. Or Velocity. Or Turbine. But please, if you can avoid plain JSP's, then stay away from them. They lead to all kinds of nastiness in your apps.

That, together with other projects like Hibernate, which is a very good persistence layer (so good that it's going to become the new JDO; they're already adopting HQL for the new EJB persistence) and Spring, which you already seem to know, you can build much more elegant apps than using JSP and servlets.

These days, so long as you are using a real language, you can find really good tools to perform persistence automatically, freeing you to have a wonderfully tidy place to put your business logic.

Having said that, it's not cut and dried. Stored procedures allow you to perform logic on your data. And if you use it for that, i.e., Data related logic, then you're fine. If you intrude into the world of business logic sitting in the database, you're going to run into problems very quickly... no extensibility, harder to test, etc.

So:

1. Make sure you're using a language that allows you to perform logic somewhere that is not a stored procedure and not a script inside an HTML page
2. Understand the difference between business logic and data related logic
3. Do your best to understand the potential for you to want to alter databases

Stored procedures are definitly a good idea once the requirements/design are finalized, but it's a hard arguement to make while developing unless the developer also is the DBA. While some may argue that it enforces better design up front, I would remind you that most requirements/designs rarely make it from paper to code unchanged, and the development costs both in time and talent are significant with stored procedures.

If you went with stored proceedures, everytime there is a business logic change, or requirements change, your front end/business logic developers would have to wait until your DBA makes the appropriate changes to the data layer before being able to continue. For me, that's just too much wasted time

With most applications that i've done, one of the major requirements is database interoperatability. I've always been asked to make my systems portable between at least Oracle/Sybase/SQL2K. With that requirement, you would need someone trained in porting stored procedures in both PL-SQL, and T-SQL. Once you start adding in less familiar databases ( MySQL/PostgreSQL/SAP etc ) things get dicey quickly. The talent required becomes much more expensive and difficult to find.

Contrast that with writing your business logic in pure SQL92. Database porting this way is simple. translate the tables. watch for weird database quirks. translate your value objects. done. If you use java, then things are even easier now with O/R Mapping libraries such as Hibernate, Castor and JDO.

If you want the best of both worlds, and you have the skills required, just put the SQL in the code, but write it in TSQL/PLSQL as if it were a stored procedure. That way it's easier to develop, and when it's time to write the stored procedure, it's already half written. Just remember that there are very few instances where the performance requirements really justify writing a stored proceedure. Be smart where your optimize your database.

You can use Hibernate in you applications and deploy it on Geronimo to your hearts content. Hibernate is application server neutral and doesnt even require an application server! You can use it in your standalone apps as well. And I would definitely recommend using Hibernate, I have pushed it into several big commercial projects and its worked like a charm. for more info on Hibernate.

A big advantage of Velocity is that it combines a flexible templating language with ease of integration into existing applications and frameworks. Because of this, a lot of java-based web frameworks include Velocity support. Struts, WebWork, Turbine, Maverick, Spring, to name a few. Using Velocity it's also possible to roll your own web markup language with Velocity as a base, as the folks on the Roller team have done.

In addition, Velocity is more than just a web scripting language. (as opposed to JSP which is almost exclusively that). Besides using it to create web pages in a webapp, I have made Velocity templates to assist my applications in sending email and have made templates to auto-generate code to help with my object/relational mapping. There's also a translation to C# called NVelocity.

If you want a good ORM, try Hibernate, it's really good, it's database-independent, works well with J2EE appservers, and has good support. Oh and it's open source (I don't know if BC4J is open source).
I think this is the kind of software that really makes Java superior to .NET: there aren't any good ORM's yet, some are coming together but they still have a long way to go (like thona's EntityBroker, which looks as though it's going to be really good but it's just not there yet); MS's own objectSpaces does not look as advanced as Hibernate or Cayenne (another java open source ORM), and it's not even out yet, and the first version will work only with SQL Server (what a surprise). Even EntityBroker is already better than ObjectSpaces.
Of course, JDO is also behind Hibernate, is not as flexible, is cumbersome to use... but the thing with .NET is that I don't see so many open source projects for that platform. Yes, I know it's relatively new, but even some migration efforts from java to .net have been frustrated because of design differences.

ESR, once more, is publicity-whoring on a subject he either knows nothing about, or chooses to be deliberately ignorant of. Any brief perusal of the Java scene will uncover an enormous amount of Open Source work going on, some of it very high quality. (And much less so, of course, but that's the same all over).

What ESR really means is that there's a lack of adoption of Java from Unix/C programmers. This has nothing whatsoever to do with whether Java is Open Source or not, and everything to do with the perception amongst such programmers (whether deserved or not), of the Java language itself. People don't choose Perl, Python or Ruby over Java because the former are open source. People choose them because they prefer using the scripting languages.

I have this feeling that Scott McNealy isn't sitting there thinking "Damn, I guess if we totally cede control over this language, all those Unix nerds who hate Java anyway are going to drop their copies of Python and come rushing to embrace us!"

Charles Miller

Personnaly I think Jython/Tapestry /Hibernate may be the ultimate web development platform, but I haven't used Zope much... I've witnessed that the Struts/EJB approach is not very productive.

My point here is that your accessor logic (so-called middleware) is what manifests the "foreign" relationship and if that's screwed then your app just doesn't work.

Well, there are two ways of looking at the typical system. Take a web application as an example: Either a) a database is where good objects go to rest when you don't need them, or b) your code is basically an engine for transforming HTTP requests into SQL statements, and then transforming SQL result sets into HTML.

I think you and I are in the first group. The database-centric approach is popular, but I think it is pretty limited, and it introduces too much design inertia. These days I just write my objects in code, and then use an O/R mapper like Hibernate to generate my SQL. If, that is, I use a database at all. Those who can't imagine life without databases should contemplate Google's architecture. Or take a look at Prevayler, a radically different way to build apps.

You've either got the middleware right or not.

Well, here I'd disagree. If referential integrity checks in the database are pretty cheap, I don't see anything wrong with a belt-and-suspenders approach. Even with extensive unit testing and pair programming, I can't so far get my bug rate much below one bug per month. If the database can catch some of those bugs sooner, I'm willing to trade a smidgen of performance.

Of course, as I'm writing this, it occurs to me that databases aren't so great for expressing all the constraints on the data anyhow; if I really want a mechanism for double-checking persistent data, I should just put it in the persistence layer. That would allow me to use the same mechanism on all data, persistent or not.

Ok! You've convinced me. Foreign key constraints are the wrong solution to the problem.

Having recently reviewed about 25 different O-R mapping tools, including top finishers Apache OJB, Oracle TopLink and Hibernate, I feel comfortable saying that this is the best online mapping site. What's that? Geography you say? Oh, oops, sorry, O-R on the brain. Carry on.

However, when you have more active objects- which generally arise when you are actually doing good OO design and programming- the interface falls apart some. What if I've got my data objects pointing to other complex objects, rather than just elemental/translatable types like strings, numbers, and dates? What if the state of object A depends directly on what is going on in object B?

In an OORDBMS translation system, the objects are essentially dead while in storage. Object A can point to Object B - another row in a different database which holds data from a different class- but it dead.


In my experience, hibernate solves these kinds of problems quite neatly, with support for collections, dependent objects and whatnot. I'm sure other OR mappers worth anything do the same.