Rod Johnson presents "Persistence Strategy", a talk delivered recently at the Belgium Java Users Group and brought to you online in partnership with TSS. In the talk, Rod takes a first-principles approach to explaining persistence, discusses 8 lessons learned dealing with persistence, and discusses Spring JDBC.

Watch Presentation

The lessons from the talk are:

1) Data tends to stick where it lands. You can't assume that any Java application controls the schema, and the schema may outlive the application.

2) Tools are useful, but are a bandaid solution. If you're using tools to do things that could not be done by hand - you've got problems.

3) Peristence should not be tied to a specific environment.

4) Databases are very good at what they do - but it's necessary to let them do it in a natural way.

5) Don't attempt to build your own persistence framework, unless your requirments are truly unique (like not accessing common types of persistent stores).

6) O/R mapping works well in 90-95% of cases, but many developers get burnt applying it everywhere.

7) Using JDBC directly should be a sackable [english slang for fired] offence.

8) Don't afraid to use DB specific features if you have a sound architecture (isolate them behind interfaces).

Rod also discussed how to use Spring JDBC.

I think the field of persistence has already been covered very well nowadays, and there really isn't too much left to say about it (at least everybody should have made up their minds in what corner they stand). But if I really need a talk about this, I'll rather listen to it from an expert like Gavin King (not that he is the only one).

I remember coming into a project that used a persistence layer that was more or less copied from the first J2EE expert book. I still shuddder at the memory. Had they used Hibernate, they might have survived... My motto: in places where it really makes sense, and only there, use JDBC as is. Otherwise, by all means use a full O/R mapper.

chris

Gavin King was unable to attend/speak during our Persistence BeJUG workshop,
but maybe he'll speak (again) this year at JavaPolis 2005 on migrating Hibernate to EJB3 :P

-Stephan
There is no spoon, only patterns !

Hardly fair to say that a project failed for failing to use Hibernate. Hibernate is very good O/R solution, and Gavin is an expert on the subject. But I think the points that Rod is making are very good points to be made, by someone with no specific O/R mapping agenda. Especially the first few, many developers can learn from this.

-jp

If you read my mail, my statement was they "MIGHT" have survived had they used Hibernate. Of course the persistence technology was only one factor, and I would be willing to admit that it probably was not even the most severe one.

I also didnt say that Hibernate was the only way (as someone else quoted). What I am sceptical of, and have had my (bad) experiences with, is those micro-framework layers that some people like to put on top of well-proven APIs and then sell them as a real solution. This lures developers into thinking they have solved the problem of, in this case, persistence, while in fact it is only a few low-level details (like exception handling) that have been taken away from them, and the real problems of persistence in a complex project remain untackled. After a while, there is so much code heaped on top of that layer, that there is no way back anymore.

I also did not like the particular design of the persistence code from that J2EE book, in fact, I thought it was badly designed. I cant argue this point, because I dont have the material handy, and its been a while - just a warning not to take everything as gospel that is published under some "famous" name (even if its G.K.).

chris

Rod Johnson and the Spring team have presented solutions to the J2EE community that are valuable to say the least. If you have studied persistence at all, you can see that there is no "One Solution" to the problem. Rod and his team have provided the J2EE community with a solution that enables J2EE applications to abstract away most of the details of any particular persistence choice in your enterprise. See: http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk9.html

If you insist on using Hibernate as your only solution then you are missing the point. Rod and his team have recognized that each framework has its own particular advantages... Informed J2EE Architects would do well to follow Rod's theory on persistence -- it is more of a Strategic enterprise solution than a Tactical one.

I like the presentation and the information in it. Thanks Rod. :-) and TSS for putting it up.

I think the field of persistence has already been covered
very well nowadays, and there really isn't too much left to say about
it (at least everybody should have made up their minds in what corner
they stand). But if I really need a talk about this, I'll rather listen
to it from an expert like Gavin King (not that he is the only
one).

I think Rod's opinions are valuable too. All experts have their own
agendas. The representatives from all the big guns in Java persistence
-- SolarMetric, Oracle, JBoss -- are undeniably experts, but they've
also got their own products to pitch. I'm not saying Rod is any
different; I'm just saying it's important to hear from all of them so
you can get a more balanced view and form your own opinions.

Though I would suggest that using JDBC directly is OK only if you have helper classes to reduce redundancy.

Furthermore, there is a lot of merit to Point 8 -- using stored procedures, for example, is a very modular approach to dealing with database intensive operations. Having said that, I don't recommend using long procedural or "cursor-for-loop" stored procs, and with Oracle in particular these days they're usually not needed given what the latest SQL dialects can do (analytics, cross-tabs, case statements, etc. -- all in a single statement).

Furthermore, there is a lot of merit to Point 8 -- using stored procedures, for example, is a very modular approach to dealing with database intensive operations. Having said that, I don't recommend using long procedural or "cursor-for-loop" stored procs, and with Oracle in particular these days they're usually not needed given what the latest SQL dialects can do (analytics, cross-tabs, case statements, etc. -- all in a single statement).

Sorry but I had to bite on this one. To quote Tom Kyte, Oracle guru and the man who probably knows the Oracle query cache/optimizer best when comparing dynamic SQL to stored procedures:

"I go over it time and time and time again. There
are many things to consider - increased parse times due to hard parses instead of soft, long lines to get into the library cache due to excessive latching caused by hard parses, excessive CPU used to optimize queries, trashing of the shared pool since it fills up with unique statements that will never be reused....."

In short, with Oracle, you should use SPs with bind variables whenever possible if scalability and performance are of concern. This is why I like Spring's raw approach and iBatis, because they still give me that wrapper to SPs. This is also why I will not use hibernate. Ever looked at the JDBC logs from most persistence frameworks like hibernate? It's dozens to hundreds of db hits for complex, large objects when hydrating/persisting. Absolutely crushes the DB making it impossible for it to optimize any query caching. What's worse is that one bad apple can spoil the cache for the whole group by flooding the cache with dynamic SQL.

Thankfully, spring gives us choice, the most powerful framework of all.

I think It must be better to generate type safe code to call stored procedure than to depend on third party helper library for this trivial stuff.

7) Using JDBC directly should be a sackable [english slang for fired] offence.

Thats pretty harsh, and pretty stupid.

Should using the Swing API directly be a sackable offense? After all there are XUL interpreters available.

Maybe for consistency we should access all services through SOAP, and just keep the business logic/data munging in the application, oh wait, is java the best language for business logic?

Hardly stupid once you read/learn about Spring framework JDBC template. The point is being made that you don't need to write all those try catch finally ... try catch blocks.
Its advice, and good advice, no wait maybe we should all go back to c.
I believe the "sackable" part is partly intended to be humor, but on the other hand its hard to come up with cases where straight JDBC would be a better solution that some form of JDBC Template or O/RM (short of trying to write your own persistence layer)
if you have such cases please enlighten me?

-jp

Hardly stupid once you read/learn about Spring framework JDBC template. The point is being made that you don't need to write all those try catch finally ... try catch blocks.Its advice, and good advice, no wait maybe we should all go back to c. I believe the "sackable" part is partly intended to be humor, but on the other hand its hard to come up with cases where straight JDBC would be a better solution that some form of JDBC Template or O/RM (short of trying to write your own persistence layer)if you have such cases please enlighten me?-jp

Well reducing a multitude of TCFTC's is hardly advice, its stating the obvious. Who uses cut/paste for SQL execution anyway? Everyone wraps JDBC calls in a helper class. My impression was he didn't like seeing SQL strings in java code, as opposed to calling JDBC directly.

Everyone wraps JDBC calls in a helper class

If only. In fact, they do not: I have seen contractors, consultants, offshore and in house developers all cut and paste identical try catch templates many times.

I like the point about making is sackable - although its hyperbole, it shows just how unprofessional coding practices should be taken as a serious issue and prevented.

Everyone wraps JDBC calls in a helper class

If only. In fact, they do not: I have seen contractors, consultants, offshore and in house developers all cut and paste identical try catch templates many times.I like the point about making is sackable - although its hyperbole, it shows just how unprofessional coding practices should be taken as a serious issue and prevented.

I find the idea that this shows "unprofessional coding practice" quite bizarre. I wouldn't do it myself (not anymore), but essentially:

- It is quick
- It works (and rock solid at that)
- If there is an error it is easy to spot
- The code you cut and paste (the try { } catch { } finally {}) is essentially static.

ORM is only good where it abstracts away enough about the actual database interaction so that I do not need to know anymore what it actually does 90% of the time.

If I need to understand it 50% of the time (as you did when using Entity EJBs), ORM is a burden (well I should not call Entity EJBs ORM really...).

Well reducing a multitude of TCFTC's is hardly advice, its stating the obvious. Who uses cut/paste for SQL execution anyway? Everyone wraps JDBC calls in a helper class. My impression was he didn't like seeing SQL strings in java code, as opposed to calling JDBC directly.

Actually, Rod's point was that _raw_ JDBC usage should be avoided at any cost. It's not about SQL strings in Java code: You'll have that with any sort of programmatic JDBC framework (such as Spring JDBC) as well. It's rather about coding raw JDBC API usage without a helper class - potentially with lots of copying-and-pasting.

Juergen

Well reducing a multitude of TCFTC's is hardly advice, its stating the obvious. Who uses cut/paste for SQL execution anyway? Everyone wraps JDBC calls in a helper class. My impression was he didn't like seeing SQL strings in java code, as opposed to calling JDBC directly.

Actually, Rod's point was that _raw_ JDBC usage should be avoided at any cost. It's not about SQL strings in Java code: You'll have that with any sort of programmatic JDBC framework (such as Spring JDBC) as well. It's rather about coding raw JDBC API usage without a helper class - potentially with lots of copying-and-pasting.Juergen

If ORM is not used in project then it doe's not mean it is copy/paste or some ugly code, ORM doe's not prevent crap and JDBC doe's not force wrong code (ORM is implemented on top of JDBC, if JDBC is wrong then ORM is wrong too)

ORM doe's not prevent crap and JDBC doe's not force wrong code

true

So true!
So using JDBC is evilish.....NEVER use it...mmmmm
and of course we all should use the "great" Spring JDBC template for the only reason of the JDBC Exceptions mess...?

Are not those guys getting too arrogant ? Do they really think they are the only people who can build a wrapper on top of JDBC ?
What's their point (besides "great" high level Exceptions mapping across databases)?
Across what ? In the Fortune 500 compaines as they mentioned
you do not control the schema, true but it is also true that they ALWAYS die with their database...
I have yet to see a database migration. It is already a MAJOR problem an upgrade to a next minor version....
Most likely they use more databases..

Are not those guys getting too arrogant ? Do they really think they are the only people who can build a wrapper on top of JDBC ?

No, of course not. I didn't say that at all. I merely said that using JDBC directly was a bad idea. If you want, build your own library over JDBC. Personally I don't think it's likely that it will do as good as job as Spring or iBATIS (or maybe some other third party solutions), but it will probably be a lot better than enduring TCFTC hell.

Btw that presentation was meant to consist of two separate parts: 1. persistence overview; 2. introduction to Spring JDBC. Unfortunately there was only one slot so the Spring stuff had to get folded in with the rest.

Rod

Are not those guys getting too arrogant ? Do they really think they are the only people who can build a wrapper on top of JDBC ?

No, of course not. I didn't say that at all. I merely said that using JDBC directly was a bad idea. If you want, build your own library over JDBC. Personally I don't think it's likely that it will do as good as job as Spring or iBATIS (or maybe some other third party solutions), but it will probably be a lot better than enduring TCFTC hell.Btw that presentation was meant to consist of two separate parts: 1. persistence overview; 2. introduction to Spring JDBC. Unfortunately there was only one slot so the Spring stuff had to get folded in with the rest.Rod

"
Personally I don't think it's likely that it will do as good as job as Spring or iBATIS "
but seriously what do you think you have invented with the Spring JDBC template ??
Can't believe the arrogance of this guy.....

Rod: Personally I don't think it's likely that it will do as good as job as Spring or iBATIS

Alan: but seriously what do you think you have invented with the Spring JDBC template ??
Can't believe the arrogance of this guy.....

Fact: Spring JDBC is a sophisticated framework that has been developed as a result of significant coding and testing effort by at least three individuals--one of them a DBA as well as a Java developer--over a period of 2-3 years. Along with that there have been feedback and contributions from many more individuals doing many complex projects in different environments. I did the initial design and initial coding, but it is not purely my framework, and is now far more capable than what I initially envisaged and coded.

I stated that it was my opinion that a roll-your-own framework for one project or organization would not do as good a job. Surely I'm entitled to a personal opinion?

Frankly, if you think you can do better so easily, it is you who are arrogant. Also, I have no connection to iBATIS--I just think it does an excellent job at what it does.

It is so sad to see you trying to climb the window...

"if you think you can do better so easily"
I did not say anything about building a better framework (can you read my last postings?!) BUT I said it was arrogant to state "Personally I don't think it's likely that it will do as good as job as Spring or iBATIS"

yes you can express your opinion but by doing so you can be arrogant or not. Dont you agree ?

and do not get this personal and be offended because I do not buy your (2-3 years effort) framework ...I assume you are not a kid....

It is so sad to see you trying to climb the window..."if you think you can do better so easily"I did not say anything about building a better framework (can you read my last postings?!) BUT I said it was arrogant to state "Personally I don't think it's likely that it will do as good as job as Spring or iBATIS"yes you can express your opinion but by doing so you can be arrogant or not. Dont you agree ?and do not get this personal and be offended because I do not buy your (2-3 years effort) framework ...I assume you are not a kid....

In all of your posts, you seem to like use personal attacks. I have not seen a bit of constructive info in your posts. On the contrary, Rod tried to explain it from the technical point of the viwe. If you were so great, why don't you show something of your own that can beat Spring ir IBatis. You are getting too personal. Stop acting like a spoiled brat!

"Personally I don't think it's likely that it will do as good as job as Spring or iBATIS "but seriously what do you think you have invented with the Spring JDBC template ??Can't believe the arrogance of this guy.....

I don't think anyone is claiming to have invented something earth shattering. Spring and iBATIS just encapsulate some good practices. These things have been done by just about everyone who has developed with JDBC, with varying approaches, and levels of success. The bottom line just is, that you don't want to bother your mind with 'raw JDBC' because you really do not have to.

Are not those guys getting too arrogant ? Do they really think they are the only people who can build a wrapper on top of JDBC ?

No, of course not. I didn't say that at all. I merely said that using JDBC directly was a bad idea. If you want, build your own library over JDBC. Personally I don't think it's likely that it will do as good as job as Spring or iBATIS (or maybe some other third party solutions), but it will probably be a lot better than enduring TCFTC hell.Btw that presentation was meant to consist of two separate parts: 1. persistence overview; 2. introduction to Spring JDBC. Unfortunately there was only one slot so the Spring stuff had to get folded in with the rest.Rod

If I recall correctly you to tell people they should never create their own persistence framework. Yet if one wants to use the SQL approach (which I personally prefer) then there are not a lot of options out there (you mention 2).

It's really not that hard to write a wrapper over JDBC. I'm not sure that we should pretend that it is.

In the spring JDBC code I didn't see any way to handle transactions? I admit I only looked through it fairly briefly, did I miss it?

I have written my own thin wrapper over JDBC (many years ago) and it handles transactions. It does not assume that there is a relational database underneath, and (for the SQL implementation) the SQL queries are all together in a properties file rather than scattered throughout the code. No offense, but the spring JDBC seems a little bit primitive to be offering to the world as a general solution.

Given that it still seems reasonable for people to write their own wrappers until a comprehensive general solution is available.

In the spring JDBC code I didn't see any way to handle transactions? I admit I only looked through it fairly briefly, did I miss it?

IMO transaction management is generally better addressed at service layer level than at data access code level using native transaction APIs to whatever persistence APIs. This increases reusability. For example, if you use JDBC Connection transaction methods, you can't reuse that code in a JTA environment taking advantage of global transactions.

Thus Spring JDBC doesn't provide its own transaction management. However, Spring provides powerful separate transaction management functionality, which works with Spring JDBC or any ORM tool which Spring integrates with. You can also use Spring JDBC with JTA transactions, of course.

In the spring JDBC code I didn't see any way to handle transactions? I admit I only looked through it fairly briefly, did I miss it?

IMO transaction management is generally better addressed at service layer level than at data access code level using native transaction APIs to whatever persistence APIs. This increases reusability. For example, if you use JDBC Connection transaction methods, you can't reuse that code in a JTA environment taking advantage of global transactions.

Sounds like a very valid approach. Is there a way to use the spring JDBC API without being inside of a spring container?

Is there a way to use the spring JDBC API without being inside of a spring container?

Absolutely. That part of Spring is distinct from Spring IoC or AOP, and is essentially a class library. You can use just the JDBC framework and nothing else if you want.

In general I think it is better using JDBC wrapper classes than using JDBC directly. I had seen projects where people forget closing DB connections and web site cannot accept more connections.

On the other hand, many web pages we developed may need get data from many tables. Ideally, at the beginning we can open a connection, get data from one table; reuse the connection, get data from another table; reuse the connection and get data from other tables...
Can Spring JDBC reuse one connection in a page like above?

Thanks.

John H. Xu
http://www.usanalyst.com

Forgot to say: all Spring JDBC needs for setup is a standard Java DataSource--available from JNDI if in an app server or locally with Commons DBCP or a host of other connection pools.

Forgot to say: all Spring JDBC needs for setup is a standard Java DataSource--available from JNDI if in an app server or locally with Commons DBCP or a host of other connection pools.

Hi Rod,

  It will be nice for users to have such an example available -- since this seems to be one of the top 3 reasons to use spring for people who're looking to use spring.

Is there a zip/tgz file which shows how to do this ? An article on springdeveloper/springframework could do the trick too.

Thank you,

BR,
~A

Thanks for the suggestion - yes, we need more articles that show how to use Spring features on their own rather than in a full application context. This would certainly help to understand the design of Spring's individual parts.

In the case of JdbcTemplate, the actual standalone usage pattern is very straightforward. For example:

  DataSource ds = ...;
  JdbcTemplate jt = new JdbcTemplate(ds);

  int myCount = jt.queryForInt("SELECT COUNT(*) FROM mytable");

  jt.update("UPDATE mytable SET myfield=? WHERE id=?", new Object[] {"myvalue", new Integer(1)});

Juergen

In the spring JDBC code I didn't see any way to handle transactions? I admit I only looked through it fairly briefly, did I miss it?

IMO transaction management is generally better addressed at service layer level than at data access code level using native transaction APIs to whatever persistence APIs. This increases reusability. For example, if you use JDBC Connection transaction methods, you can't reuse that code in a JTA environment taking advantage of global transactions.

Sounds like a very valid approach. Is there a way to use the spring JDBC API without being inside of a spring container?

Yes, and if you want to utilize Spring's transaction management abstraction outside of Spring's IoC container you could still do so via direct use of one of PlatformTransactionManager's implementations, TransactionTemplate and TransactionCallback in your code using library style instead of relying on the Spring container to configure and weave transactional service into your code for you.

Regards,
Dmitriy.

In the spring JDBC code I didn't see any way to handle transactions? I admit I only looked through it fairly briefly, did I miss it?

Yes, you missed it. Spring's transaction management abstraction is arguably the central capability of the application framework. All Spring data access templates participate in thread-bound transactions seamlessly. Such transactions may be Spring driven (via a DataSourceTransactionManager for working with JDBC) or JTA driven (via a JtaTransactionManager).

In most cases, you can switch transaction management strategies (scaling up from JDBC driven to 2PC with JTA) without changing application code. You can also switch without impacting any of your transaction demaraction policies (which may be set declaratively or programmatically).

It's important to note transaction demarcation happens at a higher layer than the individual data access operations. That fact, along with the fact that transaction participation concerns are abstracted away from the public Spring data access abstraction APIs like the JDBC framework is probably why you missed it.

More information on the Spring transaction abstraction and its design and capabilities is here: http://static.springframework.org/spring/docs/1.2.x/reference/transaction.html

Keith

So true!So using JDBC is evilish.....NEVER use it...mmmmmand of course we all should use the "great" Spring JDBC template for the only reason of the JDBC Exceptions mess...?Are not those guys getting too arrogant ? Do they really think they are the only people who can build a wrapper on top of JDBC ? What's their point (besides "great" high level Exceptions mapping across databases)? Across what ? In the Fortune 500 compaines as they mentionedyou do not control the schema, true but it is also true that they ALWAYS die with their database...I have yet to see a database migration. It is already a MAJOR problem an upgrade to a next minor version....Most likely they use more databases..

Alan, if you have developed a better framework please tells us about... So far you complaining has not been very constructive.
I am grateful that Spring team have developed such a great framework and is willing to spend time talking about/explaining it. Not sure how you could end up seeing it as arrogant...
PS Spring does not replace, but augments JDBC. If you choose to use JDBC (via Spring's template) you still have to write SQL by hand.

Victor,
Simply because we have different views does not mean that only your postings are constructive. I would argue that saying "OOOhh yes, thank you God! Let's use it and buy blindly whatever you see on the web" ...is "constructive"....

As far as arrogance's concerned, I personally found them quite arrogant (including their postings) and that's why I posted in such a "strong" way..but again that's my personal feeling... . If they did not mean to ... that's good to know..

As far as arrogance's concerned, I personally found them quite arrogant (including their postings) and that's why I posted in such a "strong" way..but again that's my personal feeling... . If they did not mean to ... that's good to know..

I've known Rod and Juergen for some time, and I have never witnessed them acting in an arrogant manner .. they just have some very strong opinions on certain technical subjects -- ask Rod about Entity EJBs for example.

You know, it could just be cultural .. those Brits can come across as being uppity, what with all those extra U's that they added to our English words ;-)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

those Brits can come across as being uppity, what with all those extra U's that they added to our English words ;-)Peace,Cameron Purdy

Especially the Brits from Australia and Germany!

those Brits can come across as being uppity, what with all those extra U's that they added to our English words ;-)Peace,Cameron Purdy

Especially the Brits from Australia and Germany!

Australia and Austria, actually :-)

Juergen

those Brits can come across as being uppity, what with all those extra U's that they added to our English words ;-)Peace,Cameron Purdy

Especially the Brits from Australia and Germany!

Technically, I'm both Australian and British, as a dual citizen.

Spring does not replace, but augments JDBC. If you choose to use JDBC (via Spring's template) you still have to write SQL by hand.

Exactly. Spring JDBC is designed for cases where you want full control over SQL (hence don't want an ORM tool) and don't want automated mappings from result sets to objects (hence don't even want the level of abstraction that iBATIS offers). It has many features related to more advanced RDBMS usage such as stored procedures, LOB handling, triggers throwing custom PL/SQL or other exception codes etc... If you want to get away from SQL, don't use Spring JDBC--use an ORM tool.

Spring JDBC sits on top of JDBC. It does not replace ResultSets, PreparedStatements etc: it just makes them easier to use, and removes the noise raw JDBC entails. Thus you can preserve your existing knowledge of JDBC, but have the rougher edges removed.

Rgds
Rod

Who uses cut/paste for SQL execution anyway? Everyone wraps JDBC calls in a helper class.

Oh that's funny! You might, but to extrapolate that to "Everyone" is a joke.

Several times I've encountered direct (and flaky) usage of JDBC with *no* helper class and *no* reuse except through cut and paste. Not only by junior programmers, not only by useless contractors, but as deeply ingrained "best" practices in IT departments. I have encountered active resistance to trying to create reusable helper classes - forget introducing Spring into such an environment.

I agree that O/R mapping is usually preferable to straight JDBC. But we should also not over estimate the importance of database portability or underestimate the complexity of using an O/R mapping tool.

My experience with Hibernate is that it's not as easy as it seems, with caching, lazy loading, query caching, connection pooling shit, mapping issues and what not, and when you have problems (and you will have them) it is often much harder to debug the issues.

You really have to understand the O/R mapping technology well before you start applying it. Of cours, this is obvious with any technology you apply. But IMHO, the amount of knowledge required goes quite a bit further than I would like. But that goes for most Java stuff.

Just don't think you can just drop in Hibernate and save tons of time on every project. It will more likely cost you a lot of time at first. Of course, it does offer a great deal of flexibility and saves a lot of time if you want to change things later.

I would suggest using straight JDBC on a small project. Save yourself some headaches. Keep it simple.

Kind regards,

Marc

you're right. However, I think it is the subject of persistence itself that makes for the complexity - Hibernate (and of course other OR tools) just makes the complexity more obvious, because it anticipates it and provides ready solutions.
I do agree that you should have an expert on any team of significant size who understands persistence inside out, which IMO implies that he/she has a good understanding of ORM as well.

chris

I would suggest using straight JDBC on a small project. Save yourself some headaches. Keep it simple.

JDBC is not simple.

If you want simple, you can't beat the various JDBC helpers out there (e.g. Spring) or something like iBatis.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

JDBC is not simple for cut and paste "developers"
JDBC is not simple for people that have no clue about databases but pretend they do not need to.... (because they claim to be sr architects and sr dev)
JDBC is not simple for people that got into Java just after reading the SUN online tutorial and claim to be expert..so when they use JDBC they just mess things up.
But they would mess things up using String, Hashtable not even going to Serialization, RMI and Threading ...
 

JDBC is simple for people that know what they are doing
JDBC is simple for developers with strong database background

Conclusion:
JDBC is nothing more than a wrapper on top of SQL with trivial additional functionalities. Thats a fact. Let's be realistic and stop with these bubbles

Too hard for you?
If you think JDBC is too hard you should:
1) Step down and let people who know do the job
2) use a framework for EACH API you are using in Java...but wait!! Then you need to understand the framework itself because you can STILL mess things up..
Should I use another framework on top of that ;-)
Wait!! Ahhh AOP is coming to help me. Let's inject transparently some bytecode and everybody is happy. No need to use any API ;-) ..
BTW What do developers do these days ? Learning framework's API and editing XML files
 

This is exactly what happened to C++. C++ was too complex only for lazy people looking for shortcuts....
..Java is shortening the gap for those people but I can still see horrible things around no matter how many "frameworks" you put on top of their code...

BTW What do developers do these days ? Learning framework's API and editing XML files  This is exactly what happened to C++. C++ was too complex only for lazy people looking for shortcuts......Java is shortening the gap for those people but I can still see horrible things around no matter how many "frameworks" you put on top of their code...

Sorry Alan, but I strongly disagree. Programmers today focus more on business logic than on technical issues.
ORM allows you to:

• Reduce the lines of code;
• Think of entities in terms of objects, not tables;
• Enable lazy loading and caching in a clear, coincise way.

About awful thinks and frameworks... well, EJB3 will address the issue of learning too many frameworks and, still, bad programmers will always be bad programmers, no matter the programming language, the framework, etc.

BTW What do developers do these days ? Learning framework's API and editing XML files  This is exactly what happened to C++. C++ was too complex only for lazy people looking for shortcuts......Java is shortening the gap for those people but I can still see horrible things around no matter how many "frameworks" you put on top of their code...

Sorry Alan, but I strongly disagree. Programmers today focus more on business logic than on technical issues.ORM allows you to:

• Reduce the lines of code;
• Think of entities in terms of objects, not tables;
• Enable lazy loading and caching in a clear, coincise way.

About awful thinks and frameworks... well, EJB3 will address the issue of learning too many frameworks and, still, bad programmers will always be bad programmers, no matter the programming language, the framework, etc.

"
Programmers today focus more on business logic than on technical issues. "
Are you serious ? Where do you live ? ;-)

"Programmers today focus more on business logic than on technical issues. "Are you serious ? Where do you live ? ;-)

I think he meant to say "plumbing", not technical issues.

Are you serious ? Where do you live ? ;-)

Sure I'm serious. I am using XDoclet + Spring + Hibernate and I have very little work on technical concerns.

"Programmers today focus more on business logic than on technical issues. "

Probably it is true if programmer, DBA and business analyst, manager, ... is the same persom. But I think programmers must focus on technical issues to help business analyst to focus on business.

JDBC is nothing more than a wrapper on top of SQL with trivial additional functionalities. Thats a fact. Let's be realistic and stop with these bubbles.Too hard for you?

It is not a case of JDBC being too hard. The problem for many of us is that it is too verbose. Your logic has to include details of contructing statements (especially verbose with prepared statements), and of extracting out individual fields from record sets. This can lead to a huge amount of code, and can obscure the logic of what is going on. If nothing else, ORMs can be a useful abbeviation that makes code clearer.

JDBC is nothing more than a wrapper on top of SQL with trivial additional functionalities. Thats a fact. Let's be realistic and stop with these bubbles.Too hard for you?

It is not a case of JDBC being too hard. The problem for many of us is that it is too verbose. Your logic has to include details of contructing statements (especially verbose with prepared statements), and of extracting out individual fields from record sets. This can lead to a huge amount of code, and can obscure the logic of what is going on. If nothing else, ORMs can be a useful abbeviation that makes code clearer.

I do agree! Nothing about completixy then.

JDBC is simple for people that know what they are doing

JDBC is simple for developers with strong database background

Conclusion:JDBC is nothing more than a wrapper on top of SQL with trivial additional functionalities. Thats a fact. Let's be realistic and stop with these bubbles

Too hard for you?

If you think JDBC is too hard you should:1) Step down and let people who know do the job

My guess is that you don't understand the intricacies of database-near development.

This is like saying that the driver of a racecar has to be an incredibly good mechanic. JDBC is very verbose, like you said, it's a thin wrapper. Therefor, it's incredibly hard to get even a simple connect/query/disconnect - process right. Most people just wrap their database access in a brutally flawed try/catch/finally/try/catch - pattern. The last try/catch within the finally is being used to close the connection. Even rewrapping all possible exceptions and passing them up to your error handler can be very tedious. Spring-JDBC does all of that for you. If you work in an organization with 10+ programmers I guarantee you that one of them forgets to handle a connection correctly somewhere. Suddenly, 50000+ customer accesses later your database goes down, because a network cable is faulty and your connection-closing code is sloppy.

Spring-JDBC abstracts this stuff away, it always handles it right. Your approach (have someone write database code who actually eats this stuff for breakfast and knows all the glitches of Oracle's OCI driver by heart) works exactly for a 3 person project.

JDBC is simple for people that know what they are doingJDBC is simple for developers with strong database backgroundConclusion:JDBC is nothing more than a wrapper on top of SQL with trivial additional functionalities. Thats a fact. Let's be realistic and stop with these bubblesToo hard for you?If you think JDBC is too hard you should:1) Step down and let people who know do the job

My guess is that you don't understand the intricacies of database-near development.This is like saying that the driver of a racecar has to be an incredibly good mechanic. JDBC is very verbose, like you said, it's a thin wrapper. Therefor, it's incredibly hard to get even a simple connect/query/disconnect - process right. Most people just wrap their database access in a brutally flawed try/catch/finally/try/catch - pattern. The last try/catch within the finally is being used to close the connection. Even rewrapping all possible exceptions and passing them up to your error handler can be very tedious. Spring-JDBC does all of that for you. If you work in an organization with 10+ programmers I guarantee you that one of them forgets to handle a connection correctly somewhere. Suddenly, 50000+ customer accesses later your database goes down, because a network cable is faulty and your connection-closing code is sloppy.Spring-JDBC abstracts this stuff away, it always handles it right. Your approach (have someone write database code who actually eats this stuff for breakfast and knows all the glitches of Oracle's OCI driver by heart) works exactly for a 3 person project.

Well John your guess is wrong and you should not pretend to be the only one who understands "intricacies of database-near development" .
Second, before making arrogant comments (like you were the only one (IF) to have worked on more than 3 people projects) you should know who you are talking with.
This shows how arrogant you are...but you know what...
you can fool cut and paste developers with your non sense preach and attitude. Serious people who have been working in this field for many years and know the field take your arrogant comments as they are...[######]
Ok, let me get back (before I want to reply to Rob)to serious dev while you are playing with the verbosity of JDBC...

If you think JDBC is too hard you should:
1) Step down and let people who know do the job
2) use a framework for EACH API you are using in Java...but wait!! Then you need to understand the framework itself because you can STILL mess things up..
Should I use another framework on top of that ;-)

That's right, higher levels of abstractions are for wimps. Which is why I'm surprised to see you posting on a Java site. I would have assumed you worked in assembler, or at the very least C or even C++.

JDBC is simple for people that know what they are doing

It's conceptually simple but astonishingly verbose and error prone. The huge amount of noise badly gets in the way of productivity. That clearly implies to me that it's not an ideal API for application developers.

How many lines of code does doing a simple SQL count take in raw JDBC? Is that reasonable? Bottom line, you need an abstraction. Maybe it's the Spring abstraction, iBATIS, something you build in house, but using JDBC directly every time just doesn't make sense unless you're paid by line of code.

JDBC is simple for developers with strong database background

With raw JDBC the SQL--which makes sense to developers with a strong database background--is obscured by all the noise. What I'm advocating wrt SQL-based operations is not abstracting away from SQL, but taking away that noise. So you don't lose any power and your database skills are just as relevant. The problem with JDBC isn't the SQL, it's the incidental complexity.

Rgds
Rod

If you think JDBC is too hard you should:1) Step down and let people who know do the job2) use a framework for EACH API you are using in Java...but wait!! Then you need to understand the framework itself because you can STILL mess things up..Should I use another framework on top of that ;-)

That's right, higher levels of abstractions are for wimps. Which is why I'm surprised to see you posting on a Java site. I would have assumed you worked in assembler, or at the very least C or even C++.

Should I laugh or should I think you are running out of arguments ?

JDBC is simple for people that know what they are doing

It's conceptually simple but astonishingly verbose and error prone. The huge amount of noise badly gets in the way of productivity. That clearly implies to me that it's not an ideal API for application developers. How many lines of code does doing a simple SQL count take in raw JDBC? Is that reasonable? Bottom line, you need an abstraction. Maybe it's the Spring abstraction, iBATIS, something you build in house, but using JDBC directly every time just doesn't make sense unless you're paid by line of code.

Everything has to be considered within a context. Nobody said every time but you said never! Do not take your words back. It does not look good at all...

JDBC is simple for developers with strong database background

With raw JDBC the SQL--which makes sense to developers with a strong database background--is obscured by all the noise. What I'm advocating wrt SQL-based operations is not abstracting away from SQL, but taking away that noise. So you don't lose any power and your database skills are just as relevant. The problem with JDBC isn't the SQL, it's the incidental complexity.RgdsRod

You have to be careful to take away only the noise but not the sound...

JDBC is not simple for cut and paste "developers"JDBC is not simple for people that have no clue about databases but pretend they do not need to.... (because they claim to be sr architects and sr dev)JDBC is not simple for people that got into Java just after reading the SUN online tutorial and claim to be expert..so when they use JDBC they just mess things up.But they would mess things up using String, Hashtable not even going to Serialization, RMI and Threading ... JDBC is simple for people that know what they are doingJDBC is simple for developers with strong database backgroundConclusion:JDBC is nothing more than a wrapper on top of SQL with trivial additional functionalities. Thats a fact. Let's be realistic and stop with these bubblesToo hard for you?If you think JDBC is too hard you should:1) Step down and let people who know do the job2) use a framework for EACH API you are using in Java...but wait!! Then you need to understand the framework itself because you can STILL mess things up..Should I use another framework on top of that ;-)Wait!! Ahhh AOP is coming to help me. Let's inject transparently some bytecode and everybody is happy. No need to use any API ;-) ..BTW What do developers do these days ? Learning framework's API and editing XML files  This is exactly what happened to C++. C++ was too complex only for lazy people looking for shortcuts......Java is shortening the gap for those people but I can still see horrible things around no matter how many "frameworks" you put on top of their code...

Hey Alan, don't need to be so arrogant... People may end up thinking they have the right to be stupid with you, y'know?

JDBC is simple for people that know what they are doing.

Anything and everything is simple for people who know what they are doing. Except that in this industry (perhaps elsewhere too) there are too many people who _think_ they know what they are doing. And the nightmare starts when they get their hands on JDBC (or anything else that's supposed to be "simple for people who know what they are doing".)

Actually, I take it back - the nightmare won't start until the next innocent guy comes in and tries to maintain the code written by the one who "knows what he is doing".

And the nightmare starts when they get their hands on JDBC (or anything else that's supposed to be "simple for people who know what they are doing".)Actually, I take it back - the nightmare won't start until the next innocent guy comes in and tries to maintain the code written by the one who "knows what he is doing".

It is true with any framework or API, is not it ? Some projects solve this problem by using code generation with templates writen by people who think they know what they are doing ... .
Resorce management and parameter binding with "finally" in "direct" ORM code must be as verbose as in JDBC to make it work. It doe's not mean ORM or JDBC is wrong, developer must always know what he is doing with ORM or without it.

my best advice would be "use your own common sense first". Dont assume that someone else, because they bear a "famous" name or have written this or that book hold the full and only truth.

One problem with so-called DAO's is that they often come in a one-DAO-per-table flavor, which can cause people to ignore the (cross-table) query capabilities of the database, and perform join operations programmatically in-memory. This because they are/feel forced to use the DAOs, and there is no place to attach the query to.

Of course I agree that you dont want to spread JDBC code all over your business layer. In that case I would recommend a service layer, like a "CustomerPersistenceService" (note that I dont call it a DAO, to avoid the above mentioned tendency).

When it comes to hibernate queries, I am not sure that I would alayws hide them away, unless I wanted to keep the choice of switching the query language mid-project (which I have never seen). After all, HQL is on a high enough abstraction level to match the rest of the programming environment on the business layer. I dont see how writing

service.queryCustomerWithPrefetchedAccountsWithAmountGreaterThan

is better than

query.setString(Customer c join fetch c.accounts a where a.amount > 1000);
query.execute();

(query not tested query). But in any case, I would not want to make this an ideological argument.

christian

It is not so hard to impement type safe comand per query, procedure or compound command for something more than a query "query.execute()". Command factory can be used to force command reuse "factry.getQueryCustomerCommand()", all CRUD commands can be generic. It is AOP without third party AOP framework, "helper" or "wrapper" and IoC :)

my best advice would be "use your own common sense first". Dont assume that someone else, because they bear a "famous" name or have written this or that book hold the full and only truth.
...

And what should you do next if you find that 'your common sense' turns out not to be really common?? Bury yourself in the sand (just because you want to be seen as 'the different one') and not seek advice from those who've been there,survived and are kind enough to share their survival skills(whether through books or through lines of code)??

It would be much better if we could always try make counter arguments that add value but not try to belittle other people. Most probably if there are "famous" it would be because they have earned it.

And what should you do next if you find that 'your common sense' turns out not to be really common??

dont be too worried. If the *results* are ok, that is.

not seek advice from those who've been there,survived and are kind enough to share their survival skills(whether through books or through lines of code)??

keeping your own common sense and taking advice are not mutually exclusive.

It would be much better if we could always try make counter arguments

thats what I did in the latter (agreedly more important) half of my posting, which you didnt quote.

keeping your own common sense and taking advice are not mutually exclusive.

Agree.But i thought your first line (and even your 1st post on this thread) about fame and people just following 'the leader' was not necessary. I think good points were raised in this thread and from my opinion i don't recall anyone just sucking in because of someone famous.

Anyway Christian, if i have misread your posts then i apologize. Thanks.

One problem with so-called DAO's is that they often come in a one-DAO-per-table flavor, which can cause people to ignore the (cross-table) query capabilities of the database, and perform join operations programmatically in-memory. This because they are/feel forced to use the DAOs, and there is no place to attach the query to.

The DAO pattern can be used to wrap any SQL call within a Java interface. Whilst it is true that a common starting point for a DAO tier might be to have one DAO per table, the real world dictates that multi-table joins, calls to stored procedures, and bulk update statements are needed before long and these can equally be implemented in a DAO tier.

For instance, FireStorm/DAO supports Table DAOs, View DAOs, Stored Procedure DAOs, and Custom SQL DAOs. Custom SQL DAOs can be used to expose pretty much any SQL statement as a DAO object (multi-table joins, bulk updates, etc.)

Cheers,

Andy Grove
CodeFutures Software

But this brings up my original question that once you start implementing all this sql does not the number of DAOs increase and eventually explode?

I see DAOs being implemented on a per SQL statement basis meaning that for each unique sql statement, you would have a unique DAO. This is a great way to control the sql that people and code can run on your database, however, in my experience, this results in hundreds of DAOs being developed. And, when someone comes along with a new sql statement, it results in a new DAO being created. Thus, you are developing your application forever.

But this brings up my original question that once you start implementing all this sql does not the number of DAOs increase and eventually explode?I see DAOs being implemented on a per SQL statement basis meaning that for each unique sql statement, you would have a unique DAO. This is a great way to control the sql that people and code can run on your database, however, in my experience, this results in hundreds of DAOs being developed. And, when someone comes along with a new sql statement, it results in a new DAO being created. Thus, you are developing your application forever.

Not really. Typically a DAO may represent a table, a view or a collection of tables. It is up to you on how you structure it. Each unique sql doesn't imply a new DAO. If I have 5 different queries to retrieve a customer object, then I would code these routines in the one CustomerDAO class.

Dino

I see DAOs being implemented on a per SQL statement basis meaning that for each unique sql statement, you would have a unique DAO.

Where do you see this happening? Whoever writes DAOs like this does needs to find someone who can show them how to do it properly or use a DAO generator.

my best advice would be "use your own common sense first". Dont assume that someone else, because they bear a "famous" name or have written this or that book hold the full and only truth.One problem with so-called DAO's is that they often come in a one-DAO-per-table flavor, which can cause people to ignore the (cross-table) query capabilities of the database, and perform join operations programmatically in-memory. This because they are/feel forced to use the DAOs, and there is no place to attach the query to.Of course I agree that you dont want to spread JDBC code all over your business layer. In that case I would recommend a service layer, like a "CustomerPersistenceService" (note that I dont call it a DAO, to avoid the above mentioned tendency).When it comes to hibernate queries, I am not sure that I would alayws hide them away, unless I wanted to keep the choice of switching the query language mid-project (which I have never seen). After all, HQL is on a high enough abstraction level to match the rest of the programming environment on the business layer. I dont see how writing service.queryCustomerWithPrefetchedAccountsWithAmountGreaterThanis better than query.setString(Customer c join fetch c.accounts a where a.amount > 1000);query.execute();(query not tested query). But in any case, I would not want to make this an ideological argument.christian

Did you consider using a 'query-by-criteria' approach to overcome this? I'm interesting in knowing whether you had any particular problems with that approach if you did.

Rob

overcome what? No, I havent used query by criteria much. I happen to like the expressiveness of a dedicated query language, be it SQL or (preferredly if I dont lose power) some flavor of OQL.

christian

I dont see how writing service.queryCustomerWithPrefetchedAccountsWithAmountGreaterThanis better than query.setString(Customer c join fetch c.accounts a where a.amount > 1000);query.execute();(query not tested query).

Could it be because you didn't name your service method after *what* it does, but rather *how* it does it? I mean, like that method in java.util.ArrayList is named isEmpty() rather than isTheHeadReferenceNull() or isTheNextNewElementIndexZero()?

Nice Presentation,

but i'd like to hear more about implementing the DAO pattern when your ORM provides you with transparence persistence.

Nice Presentation,but i'd like to hear more about implementing the DAO pattern when your ORM provides you with transparence persistence.

These discussions on ORM and DAO might be of interest:

http://www.codefutures.com/weblog/corporate/archives/2005/07/hibernate_suppo.html

http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html

Rod I've seen you say DTOs are evil in the past. And you say it again in this presentation. My undestanding is that you mean that from an OO perspective an object without behaviour (ie: just getters and setters) isn't really good OO practice.

Now I'm not sure if I heard this right in the presentation, but I thought at one point (where you were showing the DAO layer slide) you said something along the lines of "you can just pass "those" object right up to the view if you want". I was assuming that "those objects" were the domain objects... ?

So here's a question: in TopLink (which you appear to have some knowledge of), it's very easy to auto-generate TopLink data objects from a set of Oracle tables. The objects even maintain referential integrity through composition via Collection objects (which I presume implies joins at the SQL level). Aren't these really DTOs? They really are just a bunch of getters and setters with no business logic...

Also, could you explain how you see TopLink objects fitting (or not fitting) into a transparent persistence design as it pertains to business objects or business services.

So here's a question: in TopLink (which you appear to have some knowledge of), it's very easy to auto-generate TopLink data objects from a set of Oracle tables. The objects even maintain referential integrity through composition via Collection objects (which I presume implies joins at the SQL level). Aren't these really DTOs? They really are just a bunch of getters and setters with no business logic... Also, could you explain how you see TopLink objects fitting (or not fitting) into a transparent persistence design as it pertains to business objects or business services.

Robert,

I know that you asked the question of Rod, but I hope you won't mind if I jump in and clarify what you said, being that it was more of a question about TopLink than anything else.

Sure, TopLink can auto-generate objects from database tables (btw, this has always worked and will continue to always work from ANY database, not just from Oracle). This kind of reverse engineering is a feature that gives developers a convenient way of creating the domain objects in the common case where the tables already exist.

These objects are not special "TopLink" objects or DTO's. They are just objects, and typically they are the domain objects that the developer would then take and add their required logic to. Even though TopLink has the biggest bag of O/R mapping features on the planet it still can't simply guess your business logic from a set of database tables. That would be weird magic.

Not sure what you mean by "transparent persistence design" in "business services" but since TopLink objects are just regular objects that happen to be persisted using TopLink then whatever you have in mind will work.

-Mike

Thanks Mike. I guess I wasn't very clear with my question, and it's probably better served on a different forum.

On my last project I ran into some problems with TopLink and kept having to re-generate the TopLink objects (long story but it involved JDeveloper).

In that case I didn't put any business logic in those objects. My business "services" layer (in the SOA sense) had DAOs that would do the data access for the business objects. So for all intents and purposes I was treating the TopLink objects like DTOs. I guess I was wondering if this is another "sackable" offense.

So for all intents and purposes I was treating the TopLink objects like DTOs. I guess I was wondering if this is another "sackable" offense.

The debate how rich your persistent objects should be in terms of containing business logic doesn't really have one single answer, I guess. There are many applications out there that essentially have persistent objects as DTOs and process all business logic in service classes (which receive those persistent objects as arguments).

My main issue with DTOs is that you shouldn't have two mirror class trees, with one being the actually persistent objects and the other one being DTOs (or web form objects) that represent the same contents 1:1. There is no need for that with a modern O/R mapping tool (and a modern web framework that doesn't force you into String-only form objects).

Of course, there might be _special_ requirements that lead to DTOs: for example, special remoting needs where you need to create a representation of a persistent object tree that's optimited for wire transfer. That might lead to a different object tree structure, with minimal content (to save bandwidth).

Juergen

So for all intents and purposes I was treating the TopLink objects like DTOs. I guess I was wondering if this is another "sackable" offense.

The debate how rich your persistent objects should be in terms of containing business logic doesn't really have one single answer, I guess. There are many applications out there that essentially have persistent objects as DTOs and process all business logic in service classes (which receive those persistent objects as arguments).My main issue with DTOs is that you shouldn't have two mirror class trees, with one being the actually persistent objects and the other one being DTOs (or web form objects) that represent the same contents 1:1. There is no need for that with a modern O/R mapping tool (and a modern web framework that doesn't force you into String-only form objects).Of course, there might be _special_ requirements that lead to DTOs: for example, special remoting needs where you need to create a representation of a persistent object tree that's optimited for wire transfer. That might lead to a different object tree structure, with minimal content (to save bandwidth).Juergen

The only problem with this approach is that you assume that the model sort of matches the view portion. Or you are happy with retrieving 20 columns but you only require two columns in the view portion.

What's worse in hibernate is that I can't represent two different domain models for the same database table (this is typically useful when there are large blobs/clobs in the table so you can have a "small" object and a "heavyweight" object):- toplink is ok with this.

Generally, I don't consider DTOs as evil. Just a pattern that is applicable for certain situations.

Dino

Generally, I don't consider DTOs as evil. Just a pattern that is applicable for certain situations.

Agreed.

As Juergen alluded to I think what Rod was referring in this talk as "evil" is the when you're forced to create a DTO layer just to satisfy a web framework that doesn't natively support POJO-based data binding, like Struts.

The only problem with this approach is that you assume that the model sort of matches the view portion. Or you are happy with retrieving 20 columns but you only require two columns in the view portion.What's worse in hibernate is that I can't represent two different domain models for the same database table (this is typically useful when there are large blobs/clobs in the table so you can have a "small" object and a "heavyweight" object):- toplink is ok with this.Generally, I don't consider DTOs as evil. Just a pattern that is applicable for certain situations.Dino

what's wrong with HeavyWeightClass extends SmallClass?
or lazy component? or lazy attributes?

Peace,
Anthony

Or "projection"

What's worse in hibernate is that I can't represent two different domain models for the same database table (this is typically useful when there are large blobs/clobs in the table so you can have a "small" object and a "heavyweight" object)

Your assumption is just wrong: please refer to the Hibernate documentation.
Plus Blobs and Clobs are lazy loaded by their very nature. So the example is not very relevant

What's worse in hibernate is that I can't represent two different domain models for the same database table (this is typically useful when there are large blobs/clobs in the table so you can have a "small" object and a "heavyweight" object)

Your assumption is just wrong: please refer to the Hibernate documentation.

I did and asked and this was the response http://forum.hibernate.org/viewtopic.php?t=936049&highlight=. Please check http://www.hibernate.org/41.html. It is a workaround. My example is relevant since I don't want to open streams to Clobs/Blobs.

Dino

Your assumption is just wrong: please refer to the Hibernate documentation.

I did and asked and this was the response http://forum.hibernate.org/viewtopic.php?t=936049&highlight=. Please check http://www.hibernate.org/41.html. It is a workaround. My example is relevant since I don't want to open streams to Clobs/Blobs.DinoThis was in 2004!
Since then we released Hibernate 3 and are on our way top release the 3.1 version.

Not sure what you mean by "transparent persistence design" in "business services" but since TopLink objects are just regular objects that happen to be persisted using TopLink then whatever you have in mind will work.-Mike

Mike, just to let you know I had these questions answered by cracking my new book "Java Development with the Spring Framework" :) (page 26, 27: Persistent Domain Objects and Business Service Objects".

Yeah, it is a good idea to avoid copy 'n paste code /allways/. Don't know what this has to do with the direct JDBC thing though.

Using ORM is a good idea. Good for productivity, and more fun to program to. But there is a real danger too. I've seen several projects recently where both the analysts and developers went crazy on the object model combined with ORM, resulting in very badly optimized applications. And some things are just more straightforward in SQL than in OQL/ Objects. I've seen horrible constructions just to make something work with ORM while a simple SQL query would have sufficed.

Don't get me wrong, I prefer to use ORM as it lets you focus on your object model, is good for productivity and results in code that is easier to maintain. BUT some of the most succesfull projects I did in the past were just using direct JDBC; highly optimized and to-the-point. When done properly (sure, write a few wrappers and helpers... it's not like that is rocket science) and with dicipline, there is no reason why this couldn't work.

I have encountered situations while creating Hibernate mappings where the object model does not have a simple corresponding representation in Hibernate. This on a large scale can start skewing the object model or the database schema depending on which side you plan to keep constant. I might not be an expert at Hibernate, however I believe that most projects work with my level of expertise in ORM. If you have a Gavin in your team, that would be a different story altogether.

- Saju Thomas
Ishi Systems

Wasn't it, a right tool for the job? Nothing is 100% perfect. It's our responsibility, as developers, to select a working design, appropriate to the project.

I, personally, have been using classes similar to JDBCTemplate for many years, in a few languages: jusk ask Steve Z. what the Smalltalk approach is/was back in the days. Is JDBCTemplate new and, mysteriously, a Silver Bullet, TM? I don't think so, but... never have I heard Rod claiming that.

Is JDBCTemplate useful? you bet. Write your own, or use classes from Spring: it's you who is in the driving seat. IMHO, the value proposition of Spring lies in its usefullness, not novelty. Thanks Rod and co.

If someone feels their database skills are rusty, why not refresh them? OTOH, it pays to learn more about Spring, IBatis, Hibernate, etc., to see when they are useful. Again, one doesn't have to use them all the time, but ignorance is not all bliss...

Never use JDBC? Is ORM evil? 90%, why not 90.12345678%? If you ask me, it sounds quite infantile.

I have worked on a large ORM project that failed miserably.

Our group was tasked with developing a metadata based system where the attributes of an 'entity' are not known until runtime...they are rows of data and can change.

This caused havoc for the ORM guys and took them forever to get even the simplest functionality working.

ORM does not work well for this type of system where data is dynamically defined. Using ORM made our lives difficult.

If we had used JDBC, it would have been stupidly simple.

metadata-based systems are obviously bad candidates for orm, as there is usually nothing (at least not much) to map to.

Our group was tasked with developing a metadata based system where the attributes of an 'entity' are not known until runtime...they are rows of data and can change.

I was on the same project. We called our finished product "Oracle". (j/k)

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

In Rod's presentation he mentions using DAOs instead of sprinkling sql throughout the entire service layer. However in my experience, this can lead to an explosion of either DAO objects or methods withing those objects as you try and create individualized DAOs to meet each components unique needs. I have also heard that the DAO pattern is evil for this very reason.

Another point that Rod mentions, in relation to Hibernate and TopLink, is to not extend something like HQL into the service/business layer either. Once again, abstract these calls behind DAOs. However, I still see this resulting in an explosion of either DAO objects or methods.

How do people solve this? I am working on an application right now, that if we encapsulated all database calls behind DAO objects, we would end up with a 100 objects and be writting code forever as new requests for data come in. So I am just looking for peoples suggestions on this.

In Rod's presentation he mentions using DAOs instead of sprinkling sql throughout the entire service layer. However in my experience, this can lead to an explosion of either DAO objects or methods withing those objects as you try and create individualized DAOs to meet each components unique needs. I have also heard that the DAO pattern is evil for this very reason.Another point that Rod mentions, in relation to Hibernate and TopLink, is to not extend something like HQL into the service/business layer either. Once again, abstract these calls behind DAOs. However, I still see this resulting in an explosion of either DAO objects or methods.How do people solve this? I am working on an application right now, that if we encapsulated all database calls behind DAO objects, we would end up with a 100 objects and be writting code forever as new requests for data come in. So I am just looking for peoples suggestions on this.

Yes, you are right. You will have an explosion of DAOs. Yes, it is not as dynamic. However, you can implement dynamic portions using your own framework that shouldn't be tied to hibernate's or sql syntax. For example, you could pass in a customer object and using reflections a search can be based on the fields passed in. The reason I don't want to be tied to HQL is that hibernate can't do everything (especially in 2.1). I try to design flexibility.

The best reason that I can give to use the DAO approac is unit testing. The DAO layer should be application agnostic. It concentrates on data and has no business logic. Spring has a number of test classes to help test the DAO layer. Our objective was to improve the quality of the product.

Having said that, I have implemented systems that used toplink directly. In the end I was unit testing the business logic and the database interface together. It worked and was quite happy with the results. But you do find yourself trying to figure out whether a test failed because of the business logic or the database call. This makes testing a little more difficult.

My choice: DAO layer especially if you work in a large team.

Dino

Rod, and everyone else:
  We are trying to leverage JDBC 3.0 savepoints in our project (using Spring + Hibernate). Can it be that Hibernate does not support this feature? We would be able to use it if we used jdbc, right?

  Also, does Spring do something to "rollback" our persistent objects when a Hibernate transaction is rolled back? For what we saw, just the database state gets "corrected", but we end up with "dirty" persistent objects. Can someone explain more on this?

Rod, and everyone else:  We are trying to leverage JDBC 3.0 savepoints in our project (using Spring + Hibernate). Can it be that Hibernate does not support this feature?

You can access JDBC connection to use any JDBC feature.

We would be able to use it if we used jdbc, right?  Also, does Spring do something to "rollback" our persistent objects when a Hibernate transaction is rolled back? For what we saw, just the database state gets "corrected", but we end up with "dirty" persistent objects. Can someone explain more on this?

It doe's not make sence, just open new session after "rollback", object must not "live" outside transaction if you care about concurrency.

Hibernate does not support a savepoint concept. So while Spring does provide nested transaction demarcation(PROPAGATION_NESTED), it won't work properly with Hibernate's persistent objects - just with the underlying JDBC Connection there (through JDBC 3.0 Savepoints). This is also the reason why Spring's HibernateTransactionManager does not turn the "nestedTransactionAllowed" flag on by default, while the JDBC DataSourceTransactionManager does.

Hibernate simply does not offer a means to create a savepoint and roll back persistent object state to that savepoint. Actually, Hibernate does not offer a means to perform _any_ kind of rollback of persistent object state. Hibernate's persistent objects are effectively stale after a transaction rollback (whether full rollback or potential rollback to a savepoint) and need to be thrown away.

Juergen

Juergen, thanks a lot, that was EXACTLY the answer I needed!

Basically, there's not a graceful way to recover from the rollback, and I need to throw the potentially stale objects away.

Being able to rollback persistent objects would be very neat. If that feature existed, it should be provided by the O/R tool, and not Spring, right?

Thanks again for your time,

Fabricio (Bs As, Argentina).

FYI, we've implemented this feature in Hibernate but never commited it, because it creates some inconsistency in the object graph esp when reattached objects work together with loaded objetcs.
Plus we were not convinced by the usefulness of this feature (never found a convincing usecase, myself).

In the presentation Rod suggests that an O/R mapping tool is less appropriate if there is a 'window in data'. In do not fully understand this expression. Is it somehow related to the situation where developers work on large object models and have many different small partial 'views' of the datamodel?

Sanne

In the presentation Rod suggests that an O/R mapping tool is less appropriate if there is a 'window in data'. In do not fully understand this expression. Is it somehow related to the situation where developers work on large object models and have many different small partial 'views' of the datamodel?Sanne

There's a certain class of data access application where there is little or no business logic. They are essentially applications with a database, a data access layer, and a presentation tier.

In fact, this type of application is very common. There is a huge amount of SQL-based relational databases in production in enterprises worldwide (imagine the number of database installed since the early 1980s!). Almost all these databases have valuable business data that people need to view, and perhaps update. Also, these production databases are probably controlled by database administrators (so Java developers have to play nice).

I think the point is:

In these window-on-data applications, where Java developers have no control of the database schema, can't stop a production database, where there's no business logic required, etc, there's really no benefit of using an ORM solution.


PJ Murray

CodeFutures Software

Code Generation for Java Persistence

I think the point is:In these window-on-data applications, where Java developers have no control of the database schema, can't stop a production database, where there's no business logic required, etc, there's really no benefit of using an ORM solution.

And no benefit in using Java. Or coding anything. Just generate the code.

Honestly, I do see the benefit of using an ORM even in this situation. I've used NHibernate for situations like this. It has saved me a bundle of time.

And no benefit in using Java. Or coding anything. Just generate the code.

There's lots of approaches to developing window-on-data applications (just ask Business Objects!).

If you're a Java programmer though, then it sort of seems logical to use the programming language you know.

I agree with your comments about generating the code, of course. A database schema provides the almost perfect meta data.

If you're a Java programmer though, then it sort of seems logical to use the programming language you know.

If it trully is just a "Window on data" what is anyone programming?

A database schema provides the almost perfect meta data.

Sadly, it seldom does. Especially in the case you are describing the where the db is controlled by DBAs and applications that actually modify the data. And those names usually are not good to display. So you end up needing to map those names to something pretty. Hmmm. I wonder what sort of technology can do this easily. :)

A database schema provides the almost perfect meta data.

Sadly, it seldom does.

In my experience, it's almost ALWAYS true that you can reverse engineer an database schema (including stored procedures, etc).

The point, I think, in the presentation is that ORM technology is not appropriate for certain types of application - window on data applications being the example used.

It's hardly shocking news that there's no single perfect Java persistence technology. JDBC, JDO, EJB CMP, Hibernate, etc all have strengths and weaknesses.

A database schema provides the almost perfect meta data.

Sadly, it seldom does.

In my experience, it's almost ALWAYS true that you can reverse engineer an database schema (including stored procedures, etc)

Sure, you can reverse engineer a db. But it is not true that it always provides good metadata. Especially if a professional did the database. :)

.The point, I think, in the presentation is that ORM technology is not appropriate for certain types of application - window on data applications being the example used.

But why not? It a) allows you to rename fields not meant for display (usually the case) and b)it cuts down on development time.

It's hardly shocking news that there's no single perfect Java persistence technology. JDBC, JDO, EJB CMP, Hibernate, etc all have strengths and weaknesses.

Very true.

Recently I read a blog on DAO and is a good one to read. http://freesourceutilityhelp.googlepages.com/data-access-object-dao-pattern.html Thanks.