Slashdot Mirror

You know this same thought crossed my mind too. However, on one hand Oracle has an app server and Oracle has a EJB3-compliant O/R technology. I'm not really sure how well their app server compares to JBoss, but Toplink certainly compares pretty well to Hibernate. Hibernate does have more mindshare than JBoss, but if you compared all the technologies in Oracle's middleware suite to JBoss equivalents, it seems like the one place where Oracle would stand up best is Toplink vs. Hibernate. Maybe what would be more valuable to them would be having the Hibernate guys, particularly Gavin King, as part of Oracle. That would give them a lot more influence on the future of EJB persistence and even JDBC.

Oracle will not practically own EJB3 persistence however. Don't forget about Kodo, a recent acquisition of BEA. They've had the best JDO implementation and now have an EJB3 implementation based on it.

If you can, switch to JDO. Among all the other great benefits, DB related testing goes down in both volume and difficulty. After 2 years with JDO, I can't imagine not using it. I recommend http://www.solarmetric.com/

Just a few comments from a Java developer that has used an old version of hibernate, and hence actually understands what this article is about:

1) Please don't flame the reviewer so much, he's actually done a good job. I personally will buy the book now that he's given the review.

2) Hibernate is a Java based object relational mapping(ORM) tool. ORM deals with the transition on the persistence layer between a database and using the object classes within your program. Where this saves u time is in dealing with type conversions (for instance), but also because with good ORM utilities (like JDO - java data objects) u don't need to write any SQL or stored procs.

but wait, u say, I don't mind writing these! well, when you are dealing with larger projects, it's much easier for a tool to generate the tables or classes for u and just called object.persist() rather than writing lines and lines of code that do essentially the same thing.

3) JDO is an alternative to Hibernate for ORM. unlike Hibernate, JDO is a standard api laid out by Sun, with different providers like kodo. I think the original story goes Gavin King thought JDO sucked so he wrote his own ORM tool.

4) What about performance? Hibernate insist that their product is fast - no objections to the contrary here. Using JDO, most providers optimize their sql to match the database type. On the whole, performance is not bad, but the strengths of these products lie in point (2).

there u go. hth.

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.

That's why it's neat to see some commercial companies pick up opensource ideas such as a defects page. Take a look at SolarMetric which builds a JDO implementation. They even open sourced part of their code, I believe it handles the byte code manipulation.

If you want to get a technical feel for JDO, Solarmetric has an online document that covers all the spec basics here. It's not as in-depth as a full JDO book, but it covers JDO concepts pretty nicely in about 40 pages (if it were printed).

If you want to get a technical feel for JDO, Solarmetric has an online document that covers all the spec basics here. It's not as in-depth as a full JDO book, but it covers JDO concepts pretty nicely in about 40 pages (if it were printed).

Actually most relational JDO implementations already let you bypass the JDO layer and deal with SQL when you want to, and let you map classes to an existing schema (or even generate classes and O/R mapping data from an existing schema). At least, I know you can do all this with Kodo JDO. If you haven't checked out JDO lately, I'd say you should give it another shot. Keep in mind that the spec is barely a year old... implementations are adding features very rapidly.