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.
-
Presentation by Rod Johnson on Persistence Strategy (108 messages)
- Posted by: Floyd Marinescu
- Posted on: July 14 2005 19:55 EDT
Threaded Messages (108)
- persistence by the experts by Christian Sell on August 02 2005 18:07 EDT
- persistence by the experts by Stephan Janssen on August 02 2005 18:28 EDT
- persistence by the experts by Jason Poley on August 02 2005 19:51 EDT
- project failed w/o Hibernate by Christian Sell on August 03 2005 04:18 EDT
- persistence by the experts by john menke on August 02 2005 21:20 EDT
- persistence by the experts by tm jee on August 02 2005 22:26 EDT
- SolarMetric, Oracle, JBoss, Spring, etc. by Brian Dupre on August 03 2005 09:01 EDT
- Good points by Stu Charlton on August 04 2005 08:56 EDT
-
Good points by Erik Onnen on August 05 2005 02:36 EDT
- Good points by Juozas Baliuka on August 05 2005 03:33 EDT
-
Good points by Erik Onnen on August 05 2005 02:36 EDT
- Wow by Lyndon Samson on August 02 2005 22:52 EDT
- not really by Jason Poley on August 02 2005 23:33 EDT
-
A value by Lyndon Samson on August 03 2005 02:47 EDT
-
A value by adrian osullivan on August 03 2005 05:10 EDT
- So what by Karl Banke on August 03 2005 07:05 EDT
-
A value by Juergen Hoeller on August 03 2005 05:31 EDT
-
A value by Juozas Baliuka on August 03 2005 05:42 EDT
-
A value by Christian Sell on August 03 2005 05:48 EDT
-
A value by Alan Potsky on August 03 2005 07:12 EDT
-
A value by Rod Johnson on August 03 2005 11:17 EDT
-
A value by Alan Potsky on August 03 2005 11:40 EDT
-
A value by Rod Johnson on August 03 2005 12:26 EDT
- A value by Alan Potsky on August 03 2005 12:46 EDT
- A value by Tero Vaananen on August 03 2005 05:19 EDT
-
A value by Rod Johnson on August 03 2005 12:26 EDT
-
A value by cryptic one on August 03 2005 12:46 EDT
-
A value by Rod Johnson on August 03 2005 02:02 EDT
-
A value by cryptic one on August 03 2005 02:42 EDT
-
A value by Rod Johnson on August 03 2005 02:47 EDT
- How about a webpage get data from multiple datasources by Jack Xu on August 05 2005 08:03 EDT
-
A value by Rod Johnson on August 03 2005 03:29 EDT
-
A value by Anjan Bacchu on August 05 2005 02:49 EDT
- Standalone JdbcTemplate usage by Juergen Hoeller on August 06 2005 07:36 EDT
-
A value by Anjan Bacchu on August 05 2005 02:49 EDT
- A value by Dmitriy Kopylenko on August 03 2005 10:24 EDT
-
A value by Rod Johnson on August 03 2005 02:47 EDT
-
A value by cryptic one on August 03 2005 02:42 EDT
- Transactions by Keith Donald on August 03 2005 02:26 EDT
-
A value by Rod Johnson on August 03 2005 02:02 EDT
-
A value by Alan Potsky on August 03 2005 11:40 EDT
-
A value by Victor Yushenko on August 03 2005 11:56 EDT
-
A value by Alan Potsky on August 03 2005 12:13 EDT
-
A value by Cameron Purdy on August 03 2005 12:50 EDT
-
Brits by Alain Rogister on August 03 2005 02:07 EDT
- Brits by Juergen Hoeller on August 03 2005 03:46 EDT
- Brits by Rod Johnson on August 03 2005 04:07 EDT
-
Brits by Alain Rogister on August 03 2005 02:07 EDT
-
A value by Cameron Purdy on August 03 2005 12:50 EDT
- A value by Rod Johnson on August 03 2005 12:33 EDT
-
A value by Alan Potsky on August 03 2005 12:13 EDT
-
A value by Rod Johnson on August 03 2005 11:17 EDT
-
A value by Alan Potsky on August 03 2005 07:12 EDT
-
A value by Christian Sell on August 03 2005 05:48 EDT
-
A value by Juozas Baliuka on August 03 2005 05:42 EDT
- A value by Dave Hewitt on August 03 2005 05:54 EDT
-
A value by adrian osullivan on August 03 2005 05:10 EDT
-
A value by Lyndon Samson on August 03 2005 02:47 EDT
- not really by Jason Poley on August 02 2005 23:33 EDT
- Don't under estimate the complexities of O/R mapping by marc schipperheyn on August 03 2005 05:29 EDT
- Don't under estimate the complexities of O/R mapping by Christian Sell on August 03 2005 05:44 EDT
- Don't under estimate the complexities of O/R mapping by Cameron Purdy on August 03 2005 07:34 EDT
-
Don't under estimate the complexities of O/R mapping by Alan Potsky on August 03 2005 08:36 EDT
-
Don't under estimate the complexities of O/R mapping by Alessandro Santini on August 03 2005 09:03 EDT
-
Don't under estimate the complexities of O/R mapping by Alan Potsky on August 03 2005 09:14 EDT
- Don't under estimate the complexities of O/R mapping by Floyd Marinescu on August 03 2005 10:16 EDT
- Don't under estimate the complexities of O/R mapping by Alessandro Santini on August 03 2005 01:42 EDT
- Don't under estimate the complexities of O/R mapping by Juozas Baliuka on August 05 2005 01:39 EDT
-
Don't under estimate the complexities of O/R mapping by Alan Potsky on August 03 2005 09:14 EDT
-
Don't under estimate the complexities of O/R mapping by Steve Zara on August 03 2005 09:18 EDT
- Don't under estimate the complexities of O/R mapping by Alan Potsky on August 03 2005 09:37 EDT
-
Don't under estimate the complexities of O/R mapping by John Vance on August 03 2005 10:57 EDT
- Don't under estimate the complexities of O/R mapping by Alan Potsky on August 03 2005 11:37 EDT
-
Don't under estimate the complexities of O/R mapping by Rod Johnson on August 03 2005 11:25 EDT
- Don't under estimate the complexities of O/R mapping by Alan Potsky on August 03 2005 11:50 EDT
- Don't under estimate the complexities of O/R mapping by Henrique Steckelberg on August 03 2005 01:07 EDT
-
You don't say by Jing Xue on August 04 2005 03:27 EDT
-
You don't say by Juozas Baliuka on August 05 2005 01:30 EDT
-
to DAO or not to DAO by Christian Sell on August 05 2005 04:05 EDT
- to DAO or not to DAO by Juozas Baliuka on August 05 2005 06:31 EDT
-
to DAO or not to DAO by Twice Tshwenyane on August 05 2005 08:13 EDT
-
common sense by Christian Sell on August 05 2005 09:12 EDT
- common sense by Twice Tshwenyane on August 05 2005 11:45 EDT
-
common sense by Christian Sell on August 05 2005 09:12 EDT
-
to DAO or not to DAO by Andy Grove on August 05 2005 11:16 EDT
-
to DAO or not to DAO by Chris Johnston on August 05 2005 01:02 EDT
- to DAO or not to DAO by huc muc on August 05 2005 08:15 EDT
- to DAO or not to DAO by PJ Murray on August 08 2005 05:58 EDT
-
to DAO or not to DAO by Chris Johnston on August 05 2005 01:02 EDT
-
to DAO or not to DAO by Rob Harrop on August 05 2005 12:28 EDT
- to DAO or not to DAO by Christian Sell on August 06 2005 08:23 EDT
- to DAO or not to DAO by Jing Xue on August 10 2005 05:39 EDT
-
to DAO or not to DAO by Christian Sell on August 05 2005 04:05 EDT
-
You don't say by Juozas Baliuka on August 05 2005 01:30 EDT
-
Don't under estimate the complexities of O/R mapping by Alessandro Santini on August 03 2005 09:03 EDT
-
Don't under estimate the complexities of O/R mapping by Alan Potsky on August 03 2005 08:36 EDT
- Presentation by Rod Johnson on Persistence Strategy by Oscar Puga on August 03 2005 09:48 EDT
- Presentation by Rod Johnson on Persistence Strategy by PJ Murray on August 03 2005 19:24 EDT
- DTOs are evil... by Robert Hayes on August 03 2005 13:54 EDT
- DTOs are evil... by Mike Keith on August 03 2005 17:12 EDT
-
DTOs are evil... by Robert Hayes on August 03 2005 06:43 EDT
-
DTOs are evil... by Juergen Hoeller on August 04 2005 03:46 EDT
-
DTOs are evil... by huc muc on August 04 2005 12:36 EDT
- DTOs are evil... by Keith Donald on August 04 2005 01:25 EDT
-
DTOs are evil... by anthony patricio on August 04 2005 01:29 EDT
- DTOs are evil... by Mark N on August 04 2005 01:41 EDT
-
DTOs are evil... by Emmanuel Bernard on August 04 2005 02:39 EDT
-
DTOs are evil... by huc muc on August 04 2005 05:45 EDT
- DTOs are evil... by Emmanuel Bernard on August 05 2005 02:36 EDT
-
DTOs are evil... by huc muc on August 04 2005 05:45 EDT
-
DTOs are evil... by huc muc on August 04 2005 12:36 EDT
-
DTOs are evil... by Juergen Hoeller on August 04 2005 03:46 EDT
- DTOs are evil... by Robert Hayes on August 03 2005 10:57 EDT
-
DTOs are evil... by Robert Hayes on August 03 2005 06:43 EDT
- DTOs are evil... by Mike Keith on August 03 2005 17:12 EDT
- never use direct JDBC? by Eelco Hillenius on August 03 2005 18:04 EDT
- never use direct JDBC? by Saju Thomas on August 04 2005 00:14 EDT
- Re: never use direct JDBC? by T D on August 04 2005 09:04 EDT
- never use direct JDBC? by Saju Thomas on August 04 2005 00:14 EDT
- direct JDBC good when appropriate by Michael McCutcheon on August 04 2005 10:38 EDT
- direct JDBC good when appropriate by Christian Sell on August 04 2005 11:41 EDT
- direct JDBC good when appropriate by Cameron Purdy on August 04 2005 11:59 EDT
- A question about DAOs by Chris Johnston on August 04 2005 23:16 EDT
- A question about DAOs by huc muc on August 05 2005 12:14 EDT
- Persistence Object Rollback by Fabricio Breciano on August 05 2005 16:32 EDT
- Persistence Object Rollback by Juozas Baliuka on August 06 2005 02:26 EDT
- Persistence Object Rollback by Juergen Hoeller on August 06 2005 07:28 EDT
- Persistence Object Rollback by Fabricio Breciano on August 07 2005 03:39 EDT
- Persistence Object Rollback by Emmanuel Bernard on August 07 2005 05:33 EDT
- Window on data question by Sanne deRoever on August 09 2005 06:43 EDT
- Window on data question by PJ Murray on August 11 2005 11:05 EDT
-
Window on data question by Mark N on August 11 2005 04:43 EDT
-
Window on data question by PJ Murray on August 11 2005 06:21 EDT
-
Window on data question by Mark N on August 12 2005 09:37 EDT
-
Window on data question by PJ Murray on August 12 2005 04:00 EDT
- Window on data question by Mark N on August 12 2005 09:29 EDT
-
Window on data question by PJ Murray on August 12 2005 04:00 EDT
-
Window on data question by Mark N on August 12 2005 09:37 EDT
-
Window on data question by PJ Murray on August 11 2005 06:21 EDT
-
Window on data question by Mark N on August 11 2005 04:43 EDT
- Window on data question by PJ Murray on August 11 2005 11:05 EDT
- Re: Presentation by Rod Johnson on Persistence Strategy by guddu sk on April 22 2008 07:24 EDT
-
persistence by the experts[ Go to top ]
- Posted by: Christian Sell
- Posted on: August 02 2005 18:07 EDT
- in response to Floyd Marinescu
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 -
persistence by the experts[ Go to top ]
- Posted by: Stephan Janssen
- Posted on: August 02 2005 18:28 EDT
- in response to Christian Sell
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 ! -
persistence by the experts[ Go to top ]
- Posted by: Jason Poley
- Posted on: August 02 2005 19:51 EDT
- in response to Christian Sell
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 -
project failed w/o Hibernate[ Go to top ]
- Posted by: Christian Sell
- Posted on: August 03 2005 04:18 EDT
- in response to Jason Poley
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 -
persistence by the experts[ Go to top ]
- Posted by: john menke
- Posted on: August 02 2005 21:20 EDT
- in response to Christian Sell
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. -
persistence by the experts[ Go to top ]
- Posted by: tm jee
- Posted on: August 02 2005 22:26 EDT
- in response to Christian Sell
I like the presentation and the information in it. Thanks Rod. :-) and TSS for putting it up. -
SolarMetric, Oracle, JBoss, Spring, etc.[ Go to top ]
- Posted by: Brian Dupre
- Posted on: August 03 2005 09:01 EDT
- in response to Christian Sell
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. -
Good points[ Go to top ]
- Posted by: Stu Charlton
- Posted on: August 04 2005 08:56 EDT
- in response to Christian Sell
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). -
Good points[ Go to top ]
- Posted by: Erik Onnen
- Posted on: August 05 2005 02:36 EDT
- in response to Stu Charlton
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. -
Good points[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: August 05 2005 03:33 EDT
- in response to Erik Onnen
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. -
Wow[ Go to top ]
- Posted by: Lyndon Samson
- Posted on: August 02 2005 22:52 EDT
- in response to Floyd Marinescu
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? -
not really[ Go to top ]
- Posted by: Jason Poley
- Posted on: August 02 2005 23:33 EDT
- in response to Lyndon Samson
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 -
A value[ Go to top ]
- Posted by: Lyndon Samson
- Posted on: August 03 2005 02:47 EDT
- in response to Jason Poley
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. -
A value[ Go to top ]
- Posted by: adrian osullivan
- Posted on: August 03 2005 05:10 EDT
- in response to Lyndon Samson
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. -
So what[ Go to top ]
- Posted by: Karl Banke
- Posted on: August 03 2005 07:05 EDT
- in response to adrian osullivan
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...). -
A value[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: August 03 2005 05:31 EDT
- in response to Lyndon Samson
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 -
A value[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: August 03 2005 05:42 EDT
- in response to Juergen Hoeller
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)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 -
A value[ Go to top ]
- Posted by: Christian Sell
- Posted on: August 03 2005 05:48 EDT
- in response to Juozas Baliuka
ORM doe's not prevent crap and JDBC doe's not force wrong code
true -
A value[ Go to top ]
- Posted by: Alan Potsky
- Posted on: August 03 2005 07:12 EDT
- in response to Christian Sell
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.. -
A value[ Go to top ]
- Posted by: Rod Johnson
- Posted on: August 03 2005 11:17 EDT
- in response to Alan Potsky
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 -
A value[ Go to top ]
- Posted by: Alan Potsky
- Posted on: August 03 2005 11:40 EDT
- in response to Rod Johnson
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..... -
A value[ Go to top ]
- Posted by: Rod Johnson
- Posted on: August 03 2005 12:26 EDT
- in response to Alan Potsky
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.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.....
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. -
A value[ Go to top ]
- Posted by: Alan Potsky
- Posted on: August 03 2005 12:46 EDT
- in response to Rod Johnson
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.... -
A value[ Go to top ]
- Posted by: Yan Hu
- Posted on: August 03 2005 13:34 EDT
- in response to Alan Potsky
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! -
A value[ Go to top ]
- Posted by: Tero Vaananen
- Posted on: August 03 2005 17:19 EDT
- in response to Alan Potsky
"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. -
A value[ Go to top ]
- Posted by: cryptic one
- Posted on: August 03 2005 12:46 EDT
- in response to Rod Johnson
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. -
A value[ Go to top ]
- Posted by: Rod Johnson
- Posted on: August 03 2005 14:02 EDT
- in response to cryptic one
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. -
A value[ Go to top ]
- Posted by: cryptic one
- Posted on: August 03 2005 14:42 EDT
- in response to Rod Johnson
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? -
A value[ Go to top ]
- Posted by: Rod Johnson
- Posted on: August 03 2005 14:47 EDT
- in response to cryptic one
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. -
How about a webpage get data from multiple datasources[ Go to top ]
- Posted by: Jack Xu
- Posted on: August 05 2005 08:03 EDT
- in response to Rod Johnson
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 -
A value[ Go to top ]
- Posted by: Rod Johnson
- Posted on: August 03 2005 15:29 EDT
- in response to cryptic one
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. -
A value[ Go to top ]
- Posted by: Anjan Bacchu
- Posted on: August 05 2005 14:49 EDT
- in response to Rod Johnson
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 -
Standalone JdbcTemplate usage[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: August 06 2005 07:36 EDT
- in response to Anjan Bacchu
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 -
A value[ Go to top ]
- Posted by: Dmitriy Kopylenko
- Posted on: August 03 2005 22:24 EDT
- in response to cryptic one
Sounds like a very valid approach. Is there a way to use the spring JDBC API without being inside of a spring container?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.
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. -
Transactions[ Go to top ]
- Posted by: Keith Donald
- Posted on: August 03 2005 14:26 EDT
- in response to cryptic one
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 -
A value[ Go to top ]
- Posted by: Victor Yushenko
- Posted on: August 03 2005 11:56 EDT
- in response to Alan Potsky
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. -
A value[ Go to top ]
- Posted by: Alan Potsky
- Posted on: August 03 2005 12:13 EDT
- in response to Victor Yushenko
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.. -
A value[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: August 03 2005 12:50 EDT
- in response to Alan Potsky
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 -
Brits[ Go to top ]
- Posted by: Alain Rogister
- Posted on: August 03 2005 14:07 EDT
- in response to Cameron Purdy
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! -
Brits[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: August 03 2005 15:46 EDT
- in response to Alain Rogister
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 -
Brits[ Go to top ]
- Posted by: Rod Johnson
- Posted on: August 03 2005 16:07 EDT
- in response to Alain Rogister
Technically, I'm both Australian and British, as a dual citizen.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! -
A value[ Go to top ]
- Posted by: Rod Johnson
- Posted on: August 03 2005 12:33 EDT
- in response to Victor Yushenko
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 -
A value[ Go to top ]
- Posted by: Dave Hewitt
- Posted on: August 03 2005 05:54 EDT
- in response to Lyndon Samson
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. -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: marc schipperheyn
- Posted on: August 03 2005 05:29 EDT
- in response to Floyd Marinescu
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 -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Christian Sell
- Posted on: August 03 2005 05:44 EDT
- in response to marc schipperheyn
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 -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: August 03 2005 07:34 EDT
- in response to marc schipperheyn
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 -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Alan Potsky
- Posted on: August 03 2005 08:36 EDT
- in response to Cameron Purdy
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... -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Alessandro Santini
- Posted on: August 03 2005 09:03 EDT
- in response to Alan Potsky
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. -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Alan Potsky
- Posted on: August 03 2005 09:14 EDT
- in response to Alessandro Santini
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.
"
Programmers today focus more on business logic than on technical issues. "
Are you serious ? Where do you live ? ;-) -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Floyd Marinescu
- Posted on: August 03 2005 10:16 EDT
- in response to Alan Potsky
"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. -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Alessandro Santini
- Posted on: August 03 2005 13:42 EDT
- in response to Alan Potsky
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. -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: August 05 2005 01:39 EDT
- in response to Alan Potsky
"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. -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Steve Zara
- Posted on: August 03 2005 09:18 EDT
- in response to Alan Potsky
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. -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Alan Potsky
- Posted on: August 03 2005 09:37 EDT
- in response to Steve Zara
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. -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: John Vance
- Posted on: August 03 2005 10:57 EDT
- in response to Alan Potsky
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. -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Alan Potsky
- Posted on: August 03 2005 11:37 EDT
- in response to John Vance
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... -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Rod Johnson
- Posted on: August 03 2005 11:25 EDT
- in response to Alan Potsky
If you think JDBC is too hard you should:
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++.
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 ;-)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 -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Alan Potsky
- Posted on: August 03 2005 11:50 EDT
- in response to Rod Johnson
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... -
Don't under estimate the complexities of O/R mapping[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: August 03 2005 13:07 EDT
- in response to Alan Potsky
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? -
You don't say[ Go to top ]
- Posted by: Jing Xue
- Posted on: August 04 2005 15:27 EDT
- in response to Alan Potsky
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". -
You don't say[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: August 05 2005 01:30 EDT
- in response to Jing Xue
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. -
to DAO or not to DAO[ Go to top ]
- Posted by: Christian Sell
- Posted on: August 05 2005 04:05 EDT
- in response to Juozas Baliuka
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 -
to DAO or not to DAO[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: August 05 2005 06:31 EDT
- in response to Christian Sell
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 :) -
to DAO or not to DAO[ Go to top ]
- Posted by: Twice Tshwenyane
- Posted on: August 05 2005 08:13 EDT
- in response to Christian Sell
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. -
common sense[ Go to top ]
- Posted by: Christian Sell
- Posted on: August 05 2005 09:12 EDT
- in response to Twice Tshwenyane
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. -
common sense[ Go to top ]
- Posted by: Twice Tshwenyane
- Posted on: August 05 2005 11:45 EDT
- in response to Christian Sell
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. -
to DAO or not to DAO[ Go to top ]
- Posted by: Andy Grove
- Posted on: August 05 2005 11:16 EDT
- in response to Christian Sell
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 -
to DAO or not to DAO[ Go to top ]
- Posted by: Chris Johnston
- Posted on: August 05 2005 13:02 EDT
- in response to Andy Grove
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. -
to DAO or not to DAO[ Go to top ]
- Posted by: huc muc
- Posted on: August 05 2005 20:15 EDT
- in response to Chris Johnston
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 -
to DAO or not to DAO[ Go to top ]
- Posted by: PJ Murray
- Posted on: August 08 2005 17:58 EDT
- in response to Chris Johnston
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. -
to DAO or not to DAO[ Go to top ]
- Posted by: Rob Harrop
- Posted on: August 05 2005 12:28 EDT
- in response to Christian Sell
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 -
to DAO or not to DAO[ Go to top ]
- Posted by: Christian Sell
- Posted on: August 06 2005 08:23 EDT
- in response to Rob Harrop
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 -
to DAO or not to DAO[ Go to top ]
- Posted by: Jing Xue
- Posted on: August 10 2005 17:39 EDT
- in response to Christian Sell
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()? -
Presentation by Rod Johnson on Persistence Strategy[ Go to top ]
- Posted by: Oscar Puga
- Posted on: August 03 2005 09:48 EDT
- in response to Floyd Marinescu
Nice Presentation,
but i'd like to hear more about implementing the DAO pattern when your ORM provides you with transparence persistence. -
Presentation by Rod Johnson on Persistence Strategy[ Go to top ]
- Posted by: PJ Murray
- Posted on: August 03 2005 19:24 EDT
- in response to Oscar Puga
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 -
DTOs are evil...[ Go to top ]
- Posted by: Robert Hayes
- Posted on: August 03 2005 13:54 EDT
- in response to Floyd Marinescu
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. -
DTOs are evil...[ Go to top ]
- Posted by: Mike Keith
- Posted on: August 03 2005 17:12 EDT
- in response to Robert Hayes
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 -
DTOs are evil...[ Go to top ]
- Posted by: Robert Hayes
- Posted on: August 03 2005 18:43 EDT
- in response to Mike Keith
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. -
DTOs are evil...[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: August 04 2005 03:46 EDT
- in response to Robert Hayes
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 -
DTOs are evil...[ Go to top ]
- Posted by: huc muc
- Posted on: August 04 2005 12:36 EDT
- in response to Juergen Hoeller
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 -
DTOs are evil...[ Go to top ]
- Posted by: Keith Donald
- Posted on: August 04 2005 13:25 EDT
- in response to huc muc
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. -
DTOs are evil...[ Go to top ]
- Posted by: anthony patricio
- Posted on: August 04 2005 13:29 EDT
- in response to huc muc
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 -
DTOs are evil...[ Go to top ]
- Posted by: Mark N
- Posted on: August 04 2005 13:41 EDT
- in response to anthony patricio
Or "projection" -
DTOs are evil...[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: August 04 2005 14:39 EDT
- in response to huc muc
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 -
DTOs are evil...[ Go to top ]
- Posted by: huc muc
- Posted on: August 04 2005 17:45 EDT
- in response to Emmanuel Bernard
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 -
DTOs are evil...[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: August 05 2005 14:36 EDT
- in response to huc muc
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. -
DTOs are evil...[ Go to top ]
- Posted by: Robert Hayes
- Posted on: August 03 2005 22:57 EDT
- in response to Mike Keith
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". -
never use direct JDBC?[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: August 03 2005 18:04 EDT
- in response to Floyd Marinescu
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. -
never use direct JDBC?[ Go to top ]
- Posted by: Saju Thomas
- Posted on: August 04 2005 00:14 EDT
- in response to Eelco Hillenius
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 -
Re: never use direct JDBC?[ Go to top ]
- Posted by: T D
- Posted on: August 04 2005 21:04 EDT
- in response to Saju Thomas
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. -
direct JDBC good when appropriate[ Go to top ]
- Posted by: Michael McCutcheon
- Posted on: August 04 2005 10:38 EDT
- in response to Floyd Marinescu
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. -
direct JDBC good when appropriate[ Go to top ]
- Posted by: Christian Sell
- Posted on: August 04 2005 11:41 EDT
- in response to Michael McCutcheon
metadata-based systems are obviously bad candidates for orm, as there is usually nothing (at least not much) to map to. -
direct JDBC good when appropriate[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: August 04 2005 11:59 EDT
- in response to Michael McCutcheon
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 -
A question about DAOs[ Go to top ]
- Posted by: Chris Johnston
- Posted on: August 04 2005 23:16 EDT
- in response to Floyd Marinescu
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. -
A question about DAOs[ Go to top ]
- Posted by: huc muc
- Posted on: August 05 2005 12:14 EDT
- in response to Chris Johnston
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 -
Persistence Object Rollback[ Go to top ]
- Posted by: Fabricio Breciano
- Posted on: August 05 2005 16:32 EDT
- in response to Floyd Marinescu
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? -
Persistence Object Rollback[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: August 06 2005 02:26 EDT
- in response to Fabricio Breciano
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. -
Persistence Object Rollback[ Go to top ]
- Posted by: Juergen Hoeller
- Posted on: August 06 2005 07:28 EDT
- in response to Fabricio Breciano
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 -
Persistence Object Rollback[ Go to top ]
- Posted by: Fabricio Breciano
- Posted on: August 07 2005 15:39 EDT
- in response to Juergen Hoeller
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). -
Persistence Object Rollback[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: August 07 2005 17:33 EDT
- in response to Juergen Hoeller
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). -
Window on data question[ Go to top ]
- Posted by: Sanne deRoever
- Posted on: August 09 2005 06:43 EDT
- in response to Floyd Marinescu
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 -
Window on data question[ Go to top ]
- Posted by: PJ Murray
- Posted on: August 11 2005 11:05 EDT
- in response to Sanne deRoever
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 -
Window on data question[ Go to top ]
- Posted by: Mark N
- Posted on: August 11 2005 16:43 EDT
- in response to PJ Murray
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. -
Window on data question[ Go to top ]
- Posted by: PJ Murray
- Posted on: August 11 2005 18:21 EDT
- in response to Mark N
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. -
Window on data question[ Go to top ]
- Posted by: Mark N
- Posted on: August 12 2005 09:37 EDT
- in response to PJ Murray
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. :) -
Window on data question[ Go to top ]
- Posted by: PJ Murray
- Posted on: August 12 2005 16:00 EDT
- in response to Mark N
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. -
Window on data question[ Go to top ]
- Posted by: Mark N
- Posted on: August 12 2005 21:29 EDT
- in response to PJ Murray
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. :)
In my experience, it's almost ALWAYS true that you can reverse engineer an database schema (including stored procedures, etc)A database schema provides the almost perfect meta data.
Sadly, it seldom does..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. -
Re: Presentation by Rod Johnson on Persistence Strategy[ Go to top ]
- Posted by: guddu sk
- Posted on: April 22 2008 07:24 EDT
- in response to Floyd Marinescu
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.