Slashdot Mirror
Hibernate - A J2EE Developers Guide
What's To Like
The first thing that I liked is the way the book is written. Mr. Iverson has a very pleasant writing style that I found engaging. Not too formal and not too light. Naturally, there is a certain amount of Hibernate evangelism, but hey, if the author doesn't like the tool, then how am I supposed to feel good about it either? The evangelism does not feel like it strays from the bounds of truth, and there is much honesty in his first and last chapters where he discusses reasons for using a tool like Hibernate, and how Hibernate has influenced the design of the soon-coming version 3 of the EJB standard from Sun.
Chapters two, three and four cover the basics of using Hibernate. Each covers a different aspect, and each is independent of the other. Chapter two covers the use of the Hibernate mapping file as the reference that everything else is built from. This is the recommended mode of operation, where the database schema and data access objects are built for you. Chapters three and four are for those of us in the corporate world where the code or the database schema comes first and we have to adapt to and accommodate it.
Chapters seven and nine give the database theory-challenged amongst us a useful refresher in database relationships and transactions. The information, while provided in the context of Hibernate, serves as a useful refresher for the rest of us.
Hibernate has three query mechanisms. Given its relational database capabilities, one of the options is the use of plain old SQL, naturally. The two remaining options are the Hibernate Query Language (HQL) and the Criteria API. The HQL gets a fairly decent amount of coverage and left me to infer that it is the preferred means of expressing queries. The Criteria API gets only four and a half pages of explanation, which is still more than the single page dedicated to SQL.
The next to last chapter is a collection of real-world advice and tips for getting the best from Hibernate. This is a very useful chapter and looks like it contains good advice. The only thing I would suggest is that it's a little slim for a chapter of its own. Either the information could have been tucked in an appendix, or it could have been spread through the book in the form of embedded tips.
Naturally, the book has a website to accompany it.
What's To ConsiderThe book carries a copyright date of 2005 and a first printing date of November 2004. That being said, it should come as no surprise that the version of Hibernate covered is 2.1.2, but at the writing of this review (early April 2005) Hibernate 3 went final. I feel that the majority of the concepts and basic operations will be unchanged, but take this into account when deciding upon a purchase. While it is difficult to write books against the constantly moving target of an open-source or free software project, it is possible. I was involved in the technical review of a number of Struts books and they were challenged with the task of being available as version 1.1 was released. A massive undertaking, but one that they proved doable.
The typesetting seems crowded in this book. I'm not a white-space extremist, but I sure recognise when there's too little. The listings are often multi-page and have a slightly squashed feel to them.
Depending upon your point of view, chapter five is either a very useful annotated explanation of all of the available mappings within Hibernate, or it's a bad case of using available online documentation as filler (53 pages). Personally, I dislike this, but if you're in the market for an "all-in-one" style of book, this might work for you.
SummaryThis is a solid work that will take you from novice to a good working knowledge of Hibernate. If you can live with the fact that the book targets Hibernate 2.1.2 while the current production version available from the website is 3.0, then give this book a try.
You can purchase Hibernate - A J2EE Developers Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I'm programming Java, bitch!
Hibernate, first of all, is becoming the de facto persistance layer for all modern java webapps. Tied up with the Spring Framework for transactions and either Struts or Tapestry on the front end, it is becoming a commonplace for tons of Java work.
This book, however, I found extremely lacking. It didn't really teach me anything new that I didn't already learn from the webpages. Granted, I've been using hibernate for over a year now and have kept up with the technology, so perhaps this is still a book for someone new to the technology.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Yeah, really, it's not that bad. As a Java programmer, I've come to find out as long as you make sure you don't use more memory than you need (i.e. nulling variables that are no longer useful), things run fine... ...correction. Things run fine so long as you don't use Swing. Swing needs a serious makeover (yes I'm aware of alternatives, but Swing just looks so dang cool when it works)
Before you mod me funny, think, perhaps I was insightfully funny?
I can't believe a review of a book about Hibernate would not compare it to the book everyone recommends, Hibernate in Action. HiA is a great book, written by people who work on the project, including the lead developer. Of course, this review doesn't have much information that couldn't be obtained from skimming through the table of contents on Amazon.
Yours was a powerful, extremely engaging post that I found chock-full of interesting and insightful commentary!!!
Ironically, the word ironically is often used incorrectly.
Java isn't entirely interpreted anymore. In fact, much of it is just-in-time (JIT) compiled to machine language, meaning when you're about to run some Java code, the Java Virtual Machine compiles the byte code to native code on the fly.
.NET/Mono languages are all JIT'd, zero interpreting. Java is much the same now, it was just originally designed to be an interpreted language.
.NET/Mono have ahead-of-time (AOT) compilation, meaning you can compile your dll libraries or exe applications to native code at install time.
FYI, the various
Also,
Tech, life, family, faith: Give me a visit
They are ultra-double-plus-ungood.
If brevity is the soul of wit, then how does one explain Twitter?
SWT
Problem is, swing has been that way since the first time I saw it, in 1998!
I know the guy who did the swing grid control -- friends and I used to give him shit all the time for how slow it was.
Is it going to be replaced by C#? Perhaps, but it is possible to fully exploit it today, and with tools like Hibernate it's possible to rapidly deploy applications on a grand scheme. In today's business environment it is often a matter of getting it done fast rather than best, and if it's turning into a problem with performance it is always possible to turn to another language once you have something in place.
I never vote for anyone. I always vote against.
-- W.C. Fields
Actually, this is one technology that kinda lives up to the hype. Its an ORM that performs (in most cases) as fast as hand-written sql statements. I call that powerful and ultra high performance...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
I am curious to know if this books spend a decent amount of space on actually using Hibernate in the context of a J2EE application (i.e., instead of using CMP)? I currently work with CMP and I am not a huge fan, I am very interested in alternatives and wonder if this book is the place to start looking.
The title of the book implies that the book does cover this, but the review doesn't actually mention this specifically.
What is the latest on this battle?
There are so many soundbites floating around:
Hibernate is JDOish but does not follow Sun JDO Spec. But.. Gavin King of Hibernate became a member of JD02.0 Expert Group and would make it compatible with JDO 2.0 Spec.
JBOSS is adopting Hibernate as the underlying persistence mechanism for its Container-Managed Entity Java Beans.
EJB 3.0 rejected JDO 2.0.
So.. now I am confused. Who is the winner? Should I buy the book or not? Anyone care to enlighten us?
Perhaps blackmonday should insert a Clayton Bigsby quote here. But if not...
...or something.
Say White Space back at ya brother!
You can hold down the "B" button for continuous firing.
Whenever I see "is a powerful, ultra-high performance" I just stop reading right there. Excess positive adjectives are a sure-fire sign of misrepresentation.
Excess knee-jerk negativity, however, is usually perfectly accurate.
I know you were being sarcastic in your first post, but a lot of people (especially ex-VB6ers) don't understand that Java is JIT'd, or even what is JIT'd means.
Tech, life, family, faith: Give me a visit
IMHO significantly better...but click and decide yourself
High performance? I'm curious, as I'm heavily thinking about shifting from handwritten SQL and the Spring framework to hibernate. I do scientific research, and pull large data sets (.1 - 5M rows) out of a database to operate on.
Often, without carefully tuning these querries, I'm getting horrible performance. With well tuned querries (and appropriate indexing), performace is acceptable. If hibernate was smart enough to say - build anonymous views then join on them when it was a benefit to performance - then I'd be interested. If hibernate was smart enough to aggregate multiple rows of data down to a single row to map onto my summary data objects, I'd be interested. If I'm simply pushing the problem off to another framework, then I'm not sure if it buys me anything over my current methodology.
So, how well does hibernate handle the really complex query work?
if (java.performace >= c.performace) I.eat_hat();
Bleh:
push ax
push bx
push cx
call test_speed_C
move di,cs:[ofs_testC_result]
move ds,cs:[seg_testC_result]
move al,ds:[di+2]
call test_speed_asm
move di,cs:[ofs_testC_result]
move ds,cs:[seg_testC_result]
move ah,ds:[di+2]
cmp al,ah
jb bwahaha_msg
pop cx
pop bx
pop ax
Chicks dig asm, but I'll concede it's so-so for rapid prototyping though...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Does hibernate compare to what I currently use:
:P
* Tomcat
* WebMacro
* Custom Web Deployment platform.
The web platform has its own connection pooling, user access management (before template is evin processed), caching (of ANY object or abritary data / response), fully Java OO scripting language (thx to WebMacro), persistence, threading, database query management and resultset object representation.
Although not as good as the system where I used to work, my system is getting there.
It is scalable, fast, and very quick to develop on.
I am at a loss as to why there is so much hype on Hibernate.
I guess I will have to rtfb
....... /
Why punish the hard working engineers who make these products for having overzealous marketing dweebs go over the top?
You might be punishing yourself too by missing out on a potentially useful product. I personally just filter that marketing garbage out.
No, JAVA itself has never been an interpreted language. The Java program you write is in fact compiled, but not to native code. It's compiled to bytecode for the Java Virtual Machine, which is a stack machine(not too many physical stack machines exist nowadays, but hey, it seemed good at the time). The bytecode then can be compiled into native format as it runs inside the JVM.
Monstar L
Java JVMs are typically written in c/c++. Your comparison if flawed.
If you think Hibernate is good, then try Cayenne and really be blown away.
I am not affiliated with Cayenne at all - just a VERY satisfied customer.
http://objectstyle.org/cayenne/
To follow the usual java method naming conventions, your method should be named performAce(). Also, from a readability standpoint, a method named performXXX() should probably return void. Secondly, any C programmer worth his salt will remove some (but not all) of the vowels from a method name to mark his territory (i.e. c.prfrmce).
Lastly, would you like fries with that hat?
It's simple: I demand prosecution for torture.
Current JVMs are reasonably fast. In fact, most performance gap between java and C comes from its safety features.
Safety, however, is very important for web apps. Writing regular sites in C is just asking for C-style memory attacks, like buffer overflows.
Finally, nobody really complains about python's or perl's speed.
The Raven
Exactly my point. When I said "compiled", I was speaking of compiled to native code. Java, C# and other .NET languages are compiled, just not to native.
.NET/Mono apps depend on JITing and AOTing to get to native.
Java depends on interpretation and JITing to get to native, while
Tech, life, family, faith: Give me a visit
I thought this was a discussion about Hibernate, not the Slashdot Urban Myth about Java performance. And in some cases, you'd have to make sure that hat was edible..
The most important unanswered question: does it discuss XDoclet?
I know, many people like maintaining configuration files manually. Some people also like nailing their tongue to flaming coals.
Personally I prefer using a handful of @hibernate and @spring tags. But I haven't found a decent explanation of how to use the tags (e.g., if you use A you must also use B). It can be annoying - I only recently discovered the @hibernate.joined-subclass tag that permits me to use a common base object (for an integrated 'id' space) without creating a "kitchen sink" monster table.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
If you wanted those flame wars, you could just head over to theserverside
But on a slightly more serious note, it seems that there are moves afoot for reconciliation between EJB and JDO. There's a link with discussions here. Enjoy the reading. theserverside does have some infamous trolls and makes slashdot look like the greatest thing since sliced bread.
So does Anonymous Coward have good karma?
What you meant to type was:
.agrippa.
"I don't want to start a language flamewar, but I just finished reading a slashdot article comparing Ruby on Rails to Java + Spring/Hibernate and was hoping that was enough to interject into this conversation with the hope someone would click on my free Nintendo DS, GC, PS2, Xbox link."
Don't worry, it happens.
Well, Hibernate isn't an SQL writer. It's for translating between RDBMS and Objects. It's very good at persisting objects and getting objects from a database. It's very good at pulling large graphs of associated objects, which is a pain in the ass to do manually and difficult to do well (for me anyway).
Although it's possible to do summaries, it's not what it's for primarily. I think you'd be better off polishing up your SQL rather than learn Hibernate if that's what you're doing. Not that it would be any worse than what you're doing now (you could run the same SQL through it), it just seems like you could get bigger improvements from the time you'd spend learning it.
Hibernate can, but not for you "out of the box". Since its easily expandeable though, you can write custom hibernate types that might handle what you need to do.
I was thinking exactly the opposite: how the hell can it take 351 pages to describe how to use an object persistence library? Either the book is really padded, or the library must be really badly designed.
(Or both, of course.)
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Hey I know it's always open season on VB guys here on Slashdot, but what do they care about Java performance, JIT'd or not?
On that, would someone take time time and write a nice e-Book on JSP/JavaServlet for WikiBooks? Please! It'll only take a moment ;)
-- Bored? Check out my Portfolio
For those of us that want a simpler, faster, easier to use framework and just want to map your own queries to objects, is much better. And for those that like .NET it is available in that platform too.
e r);
Here's an example on how to execute a query called "myquery"
MyObject myobject = (MyObject)sqlMap.queryForObject("myquery",myinteg
And here is the query declaration:
<select id="myquery" parameterClass="java.lang.Integer" resultClass="mypackage.MyObject>
select * from mytable where id = #value#
</select>
Simple query to object mapping
Open Source Java Web Forum with LDAP authentication
Yeah, Java got a bum rap early on for speed. But people quickly showed that in many of Java's preferred domains, I/O latency was by far the primary reason for speed issues.
Then, people starting coding GUI apps in Java, with a misguided notion that it would be truly portable GUI apps. This is not only untrue, but a lot of people got angry because their sluggish machines couldn't handle it. This continues even today. A common comment about Eclipse, for example, is that it's a terrific IDE so long as you have a very fast machine.
These days, when you hear educated people complain about Java, it's not usually because of the speed issues anymore. It's usually language issues (Java needs that, Java shouldn't have this, etc.). The validity of these complains depends entirely on your viewpoint.
Slashdot. It's Not For Common Sense
I'll take a shot.
In theory the idea is that the "configuration" can be changed at runtime by some person who has the job "Application Deployer". So the developer maintains a n external config file.
In practice, this "Application Deployer" does not exist, and the developer is the only person who knows what the hell any of the stuff does. This makes the developer grumpy because he/she has to go digging thru a gross XML file to keep it in sync with their code. Whereas with XDoclet, the config information is right there with your code, so no hunting around, no maintaining external files.
In the case of using Hibernate, it's really a moot point, since you can use XDoclet to generate your XML file for you and still have the ability to change the XML file at runtime.
As an additional comment, EJB3 (And Hibernate3) address this metadata/config issue by using Java Annotations. I think this will pretty much kill off XDoclet.
From the Hibernate homepage:
The Hibernate Query Language, designed as a "minimal" object-oriented extension to SQL, provides an elegant bridge between the object and relational worlds. Hibernate also allows you to express queries using native SQL or Java-based Criteria and Example queries.
So...I'm guessing you're using the phrase "SQL writer" in some new and unusual way. Does "SQL writer" mean "writes SQL output to standard output"? Do you mean "SQL optimizer?"
Hibernate can only talk to RDBMSs that use SQL. It writes SQL to them and recieves SQL from them.
Mod me down and I will become more powerful than you can possibly imagine!
As fast? Ha! Simple queries by an organization that I work with developed some hibernate applications. These queries run generally 2-3 seconds slower than hand-written SQL statements. By the way these hand-written queries were finished within 2 seconds. Does anyone know if Hibernate can still ONLY JOIN two tables? They should have MEGA ultra high performance if they can finally do more than that. What kiddy applications are you all developing in which you only join two tables? And HQL? Wow that's a great feature. Having to learn a mini language that looks almost like SQL and does the job of SQL. Anyone ever heard of DAOs and how they can abstract away the native SQL code and yet still maintain performance? It's time to destroy the hibernate hype...
Or, I could continue developing my research apps, as I can do all the SQL work without issue.
I would be interested in creating large object graphs at will easily, as I do that as often as I do summaries. I do find that if I'm going to pull those graphs, sometimes writing queries in specific ways will get me vast improvements.
Oracle is annoying, in that sometimes two queries that look very similar can have different performance - sometimes 'forcing' the oracle query runner to pick a certain place to start earns you good performance gains.
This occurs often if you have a dimension table that you select one item from - say you select "bob" from the dimension table, and join to some other table. Oracle will think that's selective - even though the other table uses "bob" for 60% of its rows. You also join to that table on some other FK, which is much more selective, but doesn't look as selective to oracle, so it starts in the 'wrong' place with the query tree.
I'm curious as to how well hibernate performs under these areas. But, it sounds like it's well worth fooling around with, and teams that I work with/near have adopted it, so it's probably good to learn (even if I just put it on my resume and have another tech to say "been there".)
The parent is exactly on the mark. The forced separation of deployer/developer roles in J2EE has caused me to do lots of useless busywork since I first started using it back in the 1.0 days. I'm a contractor, and have worked in a bunch of J2EE shops since then -- and not one of them has ever made use of the ability to tweak the sorts of configuration parameters you'd typically include in your XDoclet tags. But until XDoclet started catching on, they all had to endure the development overhead of maintaining separate configuration files and source files.
In addition, the parent is also spot on that using XDoclet doesn't stop you from changing the configuration at runtime! The system still reads the configuration files and they can still be tweaked at deployment time if need be. The only thing XDoclet does is save the developer from having to maintain all those annoying XML files by hand while coding.
If it still bothers you, just think of it as embedding default configuration information into the source. Most applications, I think it's safe to say, do that in one way or another anyway.
From Hibernate in Action,
... from BID B inner join ITEM I on
Would you rather type:
select
B.ITEM_ID = I.ITEM_ID inner join CATEGORY C on
I.CATEGORY_ID = C.CATEGORY_ID inner join BID SB on
I.SUCCESSFUL_BID_ID = SB.BID_ID where C.NAME like 'Laptop%' and SB.AMOUNT > 100
than this:
from Bid bid join bid.item item where
item.category.name like 'Laptop%' and
item.successfulBid.amount > 100
Your call.
You do have a point about the schema being the noun but that doesn't really fly in a multi-tier system. You could easily argue that a single tier system is the best approach, thereby using the schema as a noun. There are serious benifits to this but I haven't seen a system that provides the necessary front end technology straight on top of a database. Although I dissagree with you I do like the lines that you seem to be thinking along.
FYI, the various .NET/Mono languages are all JIT'd, zero interpreting. Java is much the same now, it was just originally designed to be an interpreted language.
.NET/Mono have ahead-of-time (AOT) compilation, meaning you can compile your dll libraries or exe applications to native code at install time.
Wrong, and wrong.
First, off JIT doesn't mean "zero interpreting", no JIT VM compiles all code. It's simply not efficient to do so. And all that code is interpreted.
Second, Sun's first VM for Java was an interpreter, but Java was not at all designed to be an interpreted language. In fact, it was designed with allowing JIT VMs in mind. (And Sun's JIT VM was publicly released in '96, only two years after Java itself)
Also,
Yes, but please note that this is performing the compilation the JIT does ahead-of-time, which again isn't all of code. So it's not the same thing as conventional compiling to native code. (Although the difference isn't big performance-wise)
I'd rather call
MyObject obj = (MyObject)getmydamnobject(Object searchParamA, Object searchParamB);
Hell, I don't even want to have to cast it; what the hell else would I want? Why the hell would I try to cram an integer into a custom datatype?
Sadly.... ah fuckit.
Looks nice. I wish this all took less mental overhead; not saying it is *hard* persay -- just so much crap in the attic to pull down, dust off and use every time we need to write a decent prog.
We really are the mages of our time -- waving our hands in funny, highly scripted ways and producing... well, hopefully something interesting, but generally... I digress.
The above paragraph is language neutral -- we all have our own rituals. I am not referring to goats, silver daggers and moonlight here either people.
Hibernate's fans say it's the "right" way to handle extremely large, complex data models, especially if they already exist.
What you have to do is write yourself a new Java class (according a to big complex set of rules), one for each entity in the model. And there are a lot of different ways to handle various association-types and cascading-persistence requirements.
Once you've done all this, you have Hibernate's methods for "easily" loading and saving the objects.
So in a way you have to re-express an already-existing data model in code.
Anybody with experience in the tool care to argue whether it's worth the effort?
Troll. From version 1, hibernate was capable of joining multiple tables. Its in its very nature if you have any many-to-one relationships without lazy loading.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
And HQL? Wow that's a great feature. Having to learn a mini language that looks almost like SQL and does the job of SQL.
Yeah, but you can't blame Hibernate for that idea. The whole Java world seems to love pseudo-SQL: EJB-QL, JDO-QL, etc.
where there's fish, there's cats
Well seeing as IntelliJ had to create a plug-in to bring Visual Studio up to IDEA's level........I'd say Visual Studio actually sucks. Have you even used that P.O.S. After using IDEA it makes me wretch.
Then what about this?
i c-t-6036.html
http://www.myeclipseide.com/PNphpBB2+file-viewtop
Here's an analogy - you're going on vacation. Deciding whether to go to Orlando or Cabo is a top-level decision comparable to what a deployer makes. The implementation of the embedded software in the navigation avionics of your flight is comparable to what XDoclet generates. You shouldn't touch it, not without a compelling reason.
Once you accept this the benefits of using XDoclet are obvious. First, you only have to update information once - the configuration file and generated source files will be automatically updated. You don't have to worry about getting called into an urgent meeting and forgetting to update the fourth auxillary file.
Second, the XDoclet tags help document the nature of the fields and how classes are related. E.g., if I see
@hibernate.property not-null="true" unique="true" length="20"
I know a lot more about the field than "String" alone tells me. It's also another example of "write once" since I don't have to worry about a block comment getting out of sync with a configuration file.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
OT, but if your statistics are up to date then Oracle should pick the most selective index (assuming it's going to use one at all). I would consider speaking to your DBA and making sure the stats are current.
To me it makes somse sense to abstract the data access away from the business application. This metholdogy embraces the whole notion of object-oriented design, since switching out the data means you won't have to touch the business app - just the interfaces.
In my experience, the SQLphobia seems to derive from the following:
Case in point: I recently saw a post in another forum in which the OP opined they couldn't produce the actual SQL that the OR wrapper de jure was generating, which they needed to show the DBA in order to get an explanation as to why the SQL was running forever. Of course, suggesting they just write the damn SQL was an unacceptable answer.
In addition, if apps used more robust SQL implementations, much of the processing would be executed in the DBMS via SQL, which could be a career-limiting move to the army of J2EE hackers out there.
Another case in point: another thread in this topic attempts to point out how verbose/ugly SQL is with 3 or 4 joins compared to some Hibernate shorthand...conveniently overlooking the fact that, in robust DBMS's, most of the example query would be buried in a nicely maintained view in the DBMS.
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
Ok, here are a few reasons why I *wouldn't* want to use that hibernate syntax:
1. how do I separately validate the syntax & query results? Can I run it in on a command-line? In a query tool, etc?
2. how do I diagnose subtle problems caused by hibernate join failures? Exactly what sql is it running?
3. how much flexibility does it have? Can it handle outer joins? Subselects? Group bys? Aggregate functions? No? Then why use such a poor subset? Yes? Then why not just use sql?
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?
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.
Or stay away from huge, challenging, and powerful business applications.
Seriously can't imagine developing powerful business apps today without writing sql by hand.
Sure, there's plenty of simple CRUD (create, replace, update,delete) stuff that could be hidden behind something like this if you want. It's tedious stuff - but hardly difficult.
But beyond that - applications are expected to provide a greater amount of analysis than they were ten years ago. Just doing CRUD isn't enough - people also want to see simple analytical data (trends, totals, medians, averages, rolling averages) all throughout their transactional applications.
And without learning how to write some sql, you'll end up unable to provide this functionality - the app will be too slow to code and too slow to run it.
This metholdogy embraces the whole notion of object-oriented design, since switching out the data means you won't have to touch the business app - just the interfaces.
SQL is already an interface, and a rather high-level one at that. Putting interfaces around interfaces is overkill. IMO people wrap SQL because they don't like it or don't know it, not necessarily because it is inherently "bad". It "encapsulates" many collection-oriented concepts into a fairly decent standard. OO tends to allow roll-your-own collection oriented interfaces, producing inconsistcy and often reinvent the wheel in the process.
Table-ized A.I.
The new database benchmark "PolePosition" shows how much performance Hibernate costs:
c hmarks/).
http://polepos.sourceforge.net/
For overcoming the object-relational mismatch in resource constrained applications, like on mobile platforms, or where performance matters, you might want to look at the open source object database db4o (http://www.db4o.com/ which is up to 44x faster in the benchmark (http://www.db4o.com/about/productinformation/ben
Chris
But in case of Hibernate the description is really true. I have worked with many persistence layers in the past, (self written ones, Torque, some provided by the company I worked for, and Hibernate basically is the best there is, and one of the fastest. I worked with an OODB system years ago, they had so many open corners, like a lousy query language, no control over the object scope, no possibility to handle large amounts of object (you always heared that there is a flaw in the object design until they gave the hint, reverse the queries) Hibernate has solved all those things. I just wished there already was an ide, which binds JSF, Spring and Hibernate into a graphical editor, this ide would be a clear winner. Sun goes for raw JDBC , neglegting any sanity there is regarding session scope, oracle also goes for JDBC and IBM I have not seen yet (probably also does for JDBC) the other IDEs either only give helper tools to raw code with some visual editors but no database bindings, ore dont do anything.
Hibernate should not have any problems in this regard. Hibernate follows usually in its approach following strategy. Give the developers the tools for one approach which follows some standard practices, if those work out for all leave it that way, if not add a second or third way to cover the rest of the 10%,
In case if your problem you might have to go for following solutions, Iterators can handle the dataset load, maybe paging (dumping 1.5m objects into the object heap is not really preferrable) and as for the queries, hibernate has a query caching system which you can turn on optionally, so even if you thing you run a ton of queries you only might send a handful of real queries to the database... If you want to process the data parallely, you might run several app servers and have a clustered cache.
Well hibernate is very dependend on the database being beneath it, so if your database design already is excellent you probably will not get any better performance, with lousy databases you might sometimes get better performance due to the excellent caching hibernate has. But dont expect wonders. You wont get any OODB all you get is an OODB-RDB layer, but one of the best there is.
(I dont expect anything decent from JDO, since it is done by former ODMG people and DB vendors which shy interoperability like the devil shies holy water are sitting in there, that was one of the reasons why the ODMG standard was one of the lousiest ever in existence and basically rendered databases which relied entirely on it useless) But the JDO specs might prove me wrong in the long run, I somehow doubt it though once Oracle and others get a serious vote in the specs.
Well in m:n relations in hibernate you need at least three tables beneath it, so no two table join limit there. As for the queries, yes simplistic queries are faster as long as you dont hit a cache. In the typical webapp 90% of the operations are done over and over again on almost the same data, and there hibernate can shine. You can add a query cache if your query is constantly started again and again, you can start to cluster on application cache level once you hit a maximum of possible site users your VM can handle so that you still run against one DB but have clustering due to a cluster cache on the Object level.
You dont have to write any JDBC to object binding code which almost every plain JDBC app does. You basically are 99% database independent thanks to the abstracted query language and abstracted data type mapping. You have automated connection management, to keep the number of connections small.
The list of stuff Hibernate adds to this mix is endless. But dont expect to run a single query on a plain table as fast as one in JDBC. The reason for this is, all this caching and query translation, object mapping stuff comes with a small constant speed penalty which goes away once you run into the caches or you have to do bigger work in JDBC and have to start to implement the caching and mapping yourself (which you almost always have to do)
You will start to love hibernate once a customer or your boss decides to switch databases for political reasons and wants a reasonable upgrade path.
Design issue... The guy made a mistake in the DB design (you also can see it at the SQL statements) read the comments down the posting, one of the guys does explain it.
He basically set's three foreign key 1:1 relations but has forgotten about adding the key colums on one side of the relation. Why the db itself did not check that is weird to me, normally dbs cry at such situation at creation level.
This is definitely not a Hibernate issue, and if you could read more than three lines or would have bothered to read the topics you would have read the answer as well.
Actually it is there for a reason, there is a SQL standard which is broken by many databases see that as a vendor lock in, also if you want to stay in an object scope you cannot stay in SQL. There were earlier attempts to resolve the SQL-Object scope discrepancy but they did not work out too well. OQL basically gives you a big amount of database independency and resolves many of the how do I map SQL into the object realm problems very well.
Yes joins are very OO like in hibernate all you do is:
objecta.relation1.relation1 do whatever you wantwith it
That was basically the only part of the OQL which I really loved which hibernate based the HQL upon. You dont have to care whether the DB joins or subselects it you ara in a plain object scope for this.
if (java.performace >= c.performace) I.eat_hat();
e ck_section("SciMark 2.0");
open_url("http://www.shudo.net/jit/perf/");
ch
eat_hat();
Then, people starting coding GUI apps in Java, with a misguided notion that it would be truly portable GUI apps. This is not only untrue
That is odd. As I sit here typing there are two major Java GUI apps open on my desktop, which have good interfaces and work without change on Windows and Linux. I have developed my own Java GUI apps and have had no porting problems for years. How is this untrue?
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!
Many people, myself included, have made GUI apps with Java. And everyone goes in-full of optimism-and says, "This will be easy! Java makes it so that we can deploy on multiple platforms!"
While it's true, strictly, it's not really what people expect. Java means your code can execute on multiple platforms without a recompile. This is great, but it doesn't help you with deployment, OS integration, and usability. A good GUI application must address all those things, and getting it right across all platforms is very difficult (and sometimes impossible, each platform has different rules about usability).
There is also the performance issues. If you choose Swing, then you do incur a penalty, and this penalty varies depending on what Swing theme you select and what platform you choose. Often, these choices are the 'least of many evils'.
I've also developed apps for multiple platforms using Qt, and I have to say that the Qt experience in C++ and the Java experience were, all in all, about equal. Which is to say better than it would have been 10 years ago, but not painless by any stretch of the imagination.
Slashdot. It's Not For Common Sense
To an extent I agree, but there is still the issue of converting tables back and forth from the object models used in the business app.
While it's true, strictly, it's not really what people expect. Java means your code can execute on multiple platforms without a recompile. This is great, but it doesn't help you with deployment, OS integration, and usability.
I would say that it really does help significantly. I don't know of any other major language that is as easy to deploy, and I have had decades of experience. It sure isn't perfect, but compared to library and versioning issues, even within a supposedly single OS like Windows, Java has been a dream for my work.
A good GUI application must address all those things, and getting it right across all platforms is very difficult (and sometimes impossible, each platform has different rules about usability).
I would agree, but Java gets it better that almost any other system, I would argue. It gets you 90% there, and should be praised for that.
There is also the performance issues. If you choose Swing, then you do incur a penalty, and this penalty varies depending on what Swing theme you select and what platform you choose. Often, these choices are the 'least of many evils'.
I think is is far, far less of a problem that it used to be. Things have improved hugely since Java 1.3.x, and now with 1.5.x, I am finding Swing apps extremely responsive most of the time.
I know Java isn't perfect if you want to write apps that tie in to each platform in detail, but for cross platform apps, I think it is outstanding.
But I will reiterate that most people who dislike Java dislike it for the design of its library and its linguistic features and its developer culture, not because of any flaws in its implementation.
I don't want to poke a hornets nest, so please keep in mind I work with Java nearly every day, and the other language I get paid to work with is C++ (which I also dislike, somewhat). Here are some examples:
These are just a few examples of what I was really getting at.
Slashdot. It's Not For Common Sense
Hey thanks for the informative reply. Still suspicious of the value of something that thinly skins simple sql & doesn't help with complex sql - but I'll have to take a closer look.
ken
I spoke with the DBA, as well as our resident database architect. The DA was the guy who helped me shape a few querries in the not-as obvious methodology.
Also, if you want to do something interesting, like join 3 tables together, create a summary of those, then link to dimension tables from that summary - it's better to do the summary as an inner view. That way, you join on a smaller number of rows as you link to each dimension table. If you don't, then the summary step comes LAST, and you wind up doing joins on all the dimensions with the full rowset. It's a HUGE difference in performance (think: 15 seconds vs. 2 hours).
Things get interesting when you're working with huge data sets.
I know this comment will never get seen, but I'll bite anyways. The situation I'll give may not be quite right, because I'm writing this on the fly... Situation:Accessing a LARGE ArrayList. This is the last time it will be needed. Due to the function that it calls during it's loop, you get an out of memory error. Here's what you might do... for(int i=0; imyList.size(); i++) { iUseMemory(myList.get(i)); myList.set(i,null); } ...and voila. It helps out the memory problem. Garbage Collector is great, but can't do everything.
Before you mod me funny, think, perhaps I was insightfully funny?