|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 14
Messages: 14
Messages: 14
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Better SQLExceptions in Java 6
Heinz Kabutz' latest JavaSpecialists newsletter is "Better SQLExceptions in Java 6," detailing the new exception hierarchy available with JDBC 4.0.
His coda is interesting:This is all very nice, but something like this should have been available in Java 1.0. To now go back and fix all the legacy code is just not practical. New code is usually done with the Java Persistence API, not direct JDBC calls. Still, I am pleased to see this finally being added to JDBC. So... is that actually true? While a number of projects are able to use JPA (because it's not tied specifically to Java EE), is it valid to say that code is "usually done" with JPA over JDBC?
|
|
|
Message #226689
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
The new exceptions aren't enough of an improvement.
For example, if you have a constraint violation, your DB knows what constaint is being violated, and if it told your application it could translate it into an intelligent error message.
But no, we still just get a string containing the entire error message, and a SQL state.
|
|
|
Message #226692
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
For example, if you have a constraint violation, your DB knows what constaint is being violated, and if it told your application it could translate it into an intelligent error message.
But no, we still just get a string containing the entire error message, and a SQL state.
For this, you have to standardize the error messages / codes of each DBMS first. Tell that to the DB vendors. Anyway, if your application generates a constraint exception it's not the fault of your database (which has to complain).
|
|
|
Message #226694
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
For this, you have to standardize the error messages / codes of each DBMS first.
No, you don't. All you need are named constaints. I believe most databases support them. So when the DB says constaint USER_UNIQUE_NAME was violated, your application knows that you just tried to create a duplicate user entry and it should prompt for a different username.
Anyway, if your application generates a constraint exception it's not the fault of your database (which has to complain).
Uhuh, and this violates the DRY principle. So I declaritively specify a constraint in the DDL for my database, and then I write a bunch of procedural code to do the exact same thing. Or maybe I use XML or annotations + a third-party library do the checking. It's still being repeated, both in the CPU sense and in the code sense. The database is going to check the constraint anyway. Databases are good at that kind of thing, and provide a nice, clean, declarative language for specifying many common constraints.
What's wrong with letting the database do what it is good at and then report it back to the application?
|
|
|
Message #226698
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
For this, you have to standardize the error messages / codes of each DBMS first. No, you don't. All you need are named constaints. I believe most databases support them. So when the DB says constaint USER_UNIQUE_NAME was violated, your application knows that you just tried to create a duplicate user entry and it should prompt for a different username.
Ok, without standardization of exception responses, it's up to your application to disassemble the constraints (if available, hopefully). That's what I said.
Anyway, if your application generates a constraint exception it's not the fault of your database (which has to complain). Uhuh, and this violates the DRY principle. So I declaritively specify a constraint in the DDL for my database, and then I write a bunch of procedural code to do the exact same thing. Or maybe I use XML or annotations + a third-party library do the checking. It's still being repeated, both in the CPU sense and in the code sense. The database is going to check the constraint anyway. Databases are good at that kind of thing, and provide a nice, clean, declarative language for specifying many common constraints.
What's wrong with letting the database do what it is good at and then report it back to the application?
My understanding of a database is a generic, at least ANSI SQL compliant persistence storage. Today, with my domain model, I develop the DDL for the database (hey, we have JPA(/Hibernate/TopLink/..) + Annotations now). If my business logic, model or data access layer is not aware of logical (!) constraints, it's the fault of my application. In my opinion, the database's constraint ensures integrity to the database only. Relying on other layers regarding the DRY principle is no excuse for a bad use case modeling (e.g. a product providing MySQL support for InnoDB and MyISAM, both are JDBC compliant database engines).
|
|
|
Message #226723
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
Relying on other layers regarding the DRY principle is no excuse for a bad use case modeling (e.g. a product providing MySQL support for InnoDB and MyISAM, both are JDBC compliant database engines).
Since when do use cases mention database technologies? They're supposed to be from the user perspective.
Ok, let's say you have a requirement to support multiple database engines, some with vastly different capabilities. In that case I can better understand wanting to push things up into the application layer.
If my business logic, model or data access layer is not aware of logical (!) constraints, it's the fault of my application.
What I'm suggesting is far from a lack of awareness. The application has to be very aware of the containts, it simply doesn't have to provide the enforcement mechanism. It still must translate what the database tells it into meaningful results.
Today, with my domain model, I develop the DDL for the database (hey, we have JPA(/Hibernate/TopLink/..) + Annotations now).
In some cases a technology stack like this adds tremendous value. In others it is just excess baggage. In some cases thinking of your domain in OO terms is better than in relational terms. In some cases relational terms are better. And in many cases it doesn't make that big of a difference.
I think it could greatly simplify many applications to have a standard way for the database to more effectively communicate errors back to the application, so that the application can interpret them and take necessary actions.
|
|
|
Message #226737
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
This is all very nice, but something like this should have been available in Java 1.0. To now go back and fix all the legacy code is just not practical.
I think JDBC came in in Java 1.1... (Sorry, couldn't resist nitpicking.)
New code is usually done with the Java Persistence API, not direct JDBC calls. Still, I am pleased to see this finally being added to JDBC.
While the JPA standard for O/R mapping is great news, there are still plenty of reasons to use lower-level SQL-oriented approaches in some applications, or in particular parts of applications using O/RM. For example, the need to use stored procedures, or perform efficient set-based operations. O/RM is valuable but isn't a universal solution.
Spring has offered a rich exception hierarchy for data access, and sophisticated, configurable exception translation, since way before 1.0 (i.e. for nearly 4 years). It works on Java 1.3 and above, and not only covers JDBC but also all mainstream O/R mapping technologies, including JPA, even supporting mixed use. (JPA can throw multiple differents exceptions that aren't all derived from a JPA base class, btw.) It even allows for custom subclasses of DataAccessException to be thrown when specific database exception codes are encountered: for example, if an Oracle stored procedure raises an exception with a code above 20,000, which is allowed for application use.
Rod Johnson
Interface21 - Spring from the Source: Support, Training, Consulting
|
|
|
Message #226757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
For this, you have to standardize the error messages / codes of each DBMS first.
No, you don't. All you need are named constaints. I believe most databases support them. So when the DB says constaint USER_UNIQUE_NAME was violated, your application knows that you just tried to create a duplicate user entry and it should prompt for a different username.
Anyway, if your application generates a constraint exception it's not the fault of your database (which has to complain).
Uhuh, and this violates the DRY principle. So I declaritively specify a constraint in the DDL for my database, and then I write a bunch of procedural code to do the exact same thing. Or maybe I use XML or annotations + a third-party library do the checking. It's still being repeated, both in the CPU sense and in the code sense. The database is going to check the constraint anyway. Databases are good at that kind of thing, and provide a nice, clean, declarative language for specifying many common constraints.
What's wrong with letting the database do what it is good at and then report it back to the application?
You bring up an interesting idea but I'm wondering when it would be most worthwhile. For your standard web data-entry application I'm not sure how you'd avoid DRY principal violations. Typically you have multiple levels of validation: JavaScript, business logic, and finally database.
For many scenarios I wouldn't want to hit my database to validate - I'd rather have that closer to the client. For example, if a string was too long, etc.
|
|
|
Message #226758
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
You bring up an interesting idea but I'm wondering when it would be most worthwhile. For your standard web data-entry application I'm not sure how you'd avoid DRY principal violations. Typically you have multiple levels of validation: JavaScript, business logic, and finally database.
For many scenarios I wouldn't want to hit my database to validate - I'd rather have that closer to the client. For example, if a string was too long, etc.
How much overhead does making a (1) trip to the server, and (2) trip to the database add in real-world execution? In how many environments does it matter?
My guess is that in high-volume internet sites avoiding the trips is important. But for your average intranet application it doesn't really matter.
Also, for simple validation like length, you could access that from the db metadata and push it up the the UI.
|
|
|
Message #226767
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
You bring up an interesting idea but I'm wondering when it would be most worthwhile. For your standard web data-entry application I'm not sure how you'd avoid DRY principal violations. Typically you have multiple levels of validation: JavaScript, business logic, and finally database.
For many scenarios I wouldn't want to hit my database to validate - I'd rather have that closer to the client. For example, if a string was too long, etc.
How much overhead does making a (1) trip to the server, and (2) trip to the database add in real-world execution? In how many environments does it matter?
My guess is that in high-volume internet sites avoiding the trips is important. But for your average intranet application it doesn't really matter.
Also, for simple validation like length, you could access that from the db metadata and push it up the the UI.
I'm not knocking the idea but it just seems a bit retro to me. I think what you gain in DRY you lose in having all of your business logic/validation in a centralized location. The DB is only going to go so far in helping validate. Really, only allowing certain data types and sizes. I think most of the SQL errors that could be thrown that you'd be able to handle (not faults) would be whittled down quite a bit in development and testing.
Take a field like "phone number" for example. Other than size of the field, the database won't help with validation. So why would I want every business rule on telephones to be in my Java except maximum length? Should that validation be handled via some DAO exception trapping or alongside the area codes, dashes, extensions, etc validation?
Pulling validations from the dao metadata is also interesting and would be more viable if there was a true standard for metadata across different databases. I'm wondering if it would be better as a generate once function instead of reading the metadata dynamically. How often does the data store shape change once you are in production? Usually any change is additive and doesn't affect existing tables or columns.
I hope I'm not setting up a strawman argument here. Just that for the most part I've always been advised to consolidate business logic on the middle tier.
I can see more of your point with the duplicate record issue. Normally you'd have to start a transaction, check to see if the key already exists, and then do the insert if it is valid. If you had better exceptions coming back from the DB you may just go ahead and attempt the insert and handle the exception. That probably is more analogous to an exceptional occurrence.
|
|
|
Message #226768
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
I'm not knocking the idea but it just seems a bit retro to me.
It is...but then I spent a couple months working in LISP and I've suddenly found anomymous-inner-classes-as-functors popping up in my Java and find myself wishing for closures. Sometimes there are some good ideas hiding in old technology.
Other than size of the field, the database won't help with validation.
If your database is extenisble enough you could write a function and stick it in a check contraint to validate the phone number. With some databases you could even write the function in Java...
So why would I want every business rule on telephones to be in my Java except maximum length?
I agree. Scattering validation rules to the four winds seems like a very bad idea. Unfortunately this happens a lot. There are some rules
How often does the data store shape change once you are in production?
Too often and not often enough. But that's another issue...
I hope I'm not setting up a strawman argument here. Just that for the most part I've always been advised to consolidate business logic on the middle tier.
I'll think of this as a thought experiment...so a strawman argument would be completely acceptable...
So what exactly is business logic?
1. Point-in-time data validation rules
2. Validation of data invariants
3. Lots of other stuff..
So #1 would be something like validating that a specified credit card number actually identifies an account that matches the other identification information specified. IMHO these belong in the middle tier.
#2 would be things like lengths, not nulls, uniqueness, foreign key references, range boundaries, etc. IMHO these should be in the database tier, because the database should make certain that the invariants always hold. However, errors in regards to these validations must make it all the way back up to the user in a useful form, and at times it may be very beneficial to have them checked prior to entry into the database tier.
Frequently applications check their data-related invariants in the middle tier and not in the database tier. Two bad things arise from this. (1) is that some genius writes some code that modifies data w/o doing proper checks, and the application starts crashing because those were being treated as invariants all over the code. (2) is it becomes extremely difficult to modify the data without going through the API. Being able to occasionally attack the database with SQL without worry about completely hosing it up is very valuable from an operations perspective.
Overall, I think it would be very beneficial if the database tier and the application tier were not so strongly separated. But I'm not sure exactly how thick the divide should be. At times I think it should go away, and other times I think it should just be less like the Berlin wall and more like a Canadian border crossing (well...crossing under the old rules...).
|
|
|
Message #226769
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
Yeah, I'm hearing you. I'm a database-first developer many times. When I think of an enterprise, I think of data stores before I think of software since that is the heart of the enterprise.
Still, I think there would need to be some sort of data tier revolution before I'd chance coding my business rules (even if it is just validation) there again. I recently had to tear down Java stored procedures at a company because, while easy to write, they are not at all easy to maintain.
At the client the developers didn't have the rights to install them so every change required an email to the DBA group. Making sure the right version rolled out with the J2EE code was a pain too.
This is a bit of a tangent from the conversation but my point is that I'm conservative enough to not want to do anything too novel on the data tier. Going back to the article and your first comment I could see some usefulness for having a set of standardized exceptions over what we have now with JDBC. Spring's exception wrappings is a step in the right direction.
I'll have to read the Java 6 spec to see what they are doing.
|
|
|
Message #226810
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
At the client the developers didn't have the rights to install them so every change required an email to the DBA group.
I would call that extremely agile compared to what I've seen. I think the...difficulty...in dealing with the DBA group in large organizations has lead to some less-than-ideal technical decisions. On a number of occasions I've seen developers design around the need to make database changes solely to avoid the DB change process.
|
|
|
Message #226950
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
This is all very nice, but something like this should have been available in Java 1.0. To now go back and fix all the legacy code is just not practical.
I think JDBC came in in Java 1.1... (Sorry, couldn't resist nitpicking.)
Thanks for pointing that out, Rod, I didn't know that. The first version of Java that I really used was 1.1.
Spring has offered a rich exception hierarchy for data access, and sophisticated, configurable exception translation, since way before 1.0 (i.e. for nearly 4 years).
Perhaps I should have written: "New code is usually done with the Java Persistence API or the Spring Framework, not direct JDBC calls."
I've updated my newsletter accordingly.
Heinz
|
|
|
Message #226993
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Better SQLExceptions in Java 6
At the client the developers didn't have the rights to install them so every change required an email to the DBA group.
I would call that extremely agile compared to what I've seen. I think the...difficulty...in dealing with the DBA group in large organizations has lead to some less-than-ideal technical decisions. On a number of occasions I've seen developers design around the need to make database changes solely to avoid the DB change process.
Yeah, we've done that here too. Moved a lot of lookup code tables to configuration files to avoid DBA & data modeling overhead.
That's part of being a desinger though right? Not just purity but designing to the reality of the situation.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Only through a combination of application server clustering and application construct performance tuning can Java expect to approach the runtime performance of C++: this article attempts to address this by developing criteria for assembling applications.
(February 6, Article)
JavaSpaces has been a bit of an unknown technology for a long time. It's one of those technologies that programmers know is out there, but haven't actually used enough to say they understand what it's for or what it can do for them. JavaSpaces is, in very simple terms, a kind of client/server map, a grid in which data lives. This article walks through the creation of a simple computation server, explaining the Spaces model along the way.
(January 29, Article)
Ted Neward and other noted industry bloggers examine the heated topic of interoperability today. Watch out for what happens when worlds collide.
A companion/standalone book to Mastering EJB 2, EJB Design Patterns seeks to solidify and centralize all the cutting edge strategies and design patterns in use today.
(Book PDF Download)
Terracotta DSO is an open source technology created by Terracotta, meant to provide clustering to Java at the virtual machine level. It does so by weaving code around specific classes, which will communicate with a specific server process to retrieve and update data as needed. This article walks through getting one's feet wet with DSO.
(January 23, Article)
The fourth edition in the Mastering EJB series, this book provides in-depth coverage on the changes that come with EJB 3.0. More than 50% new and revised, the free download covers
the latest features of the new release and information on the Java Persistence API and the entities defined therein.
(July 17, Book Download)
Enterprise service buses are the preferred tools for integrating systems with heterogeneous data interchange interfaces and based on a wide array of technologies, from COBOL to CORBA to JEE. This article is an introduction to ESBs and enterprise integration using Mule, the open-source ESB.
(January 15, Article)
This three part series is based on chapter two of Groovy in Action from Manning Publications. The chapter introduces the language in a high-level fashion. After reading this series, you will have a solid understanding of Groovy fundamentals. This is part one of the three.
(January 9, Book Excerpt)
This article by Jeff McAffer and Simon Kaegi shows how the Eclipse Equinox modular runtime works, from Eclipse' perspective, and then discusses how Equinox can be embedded in a serverside application.
(January 2, Article)
In this tech talk, Iona's Oisin Hurley and Steve Vinoski discuss Iona's view of what's important around SOA design and implementation, focusing on Iona's Celtix and Artix offerings, as well as covering some of Iona's tooling and ancillary libraries, like CXF.
(December 29, Tech Talk)
This article by Daniel Rubio clearly explains many of the advantages Java EE 5 offers for developers, showing the advantages of the new platform's changes. Annotations, EJB3 (including persistence), and changes in the web tier (including the standardization of JSF) are the main highlights.
(December 19, Article)
Java Persistence with Hibernate, by Christian Bauer and Gavin King, explains Hibernate's implementation of the Java Persistence API, covering queries, fetching strategies, caching, transactions, conversations, best practices in database design, optimizations, and coverage of JBoss Seam, JBoss' application framework for JSF, EJB 3.0, and Hibernate.
(December 14, Book Excerpt)
Google Web Toolkit (GWT) lets you build Ajax applications in Java. In this tech talk, Bruce Johnson talks about what you can expect when you build your web app with GWT. Bruce also talks about using GWT with existing JavaScript libraries.
(December 11, Tech Talk)
Learn how to build a collaborative, multi-user application with Ajax Push. This talk, recorded at the Ajax Experience in October takes a complete trip through the Ajax Push pipeline, answering questions with the lessons learned from developing the ICEfaces framework.
(December 4, TechTalk)
Using a detailed case study, application architect Paulo Caroli illustrates how to effectively apply Mock objects when performing Test Driven Development (TDD).
(December 4, Article)
In chapter three of iText in Action: Creating and Manipulating PDF, Bruno Lowagie takes a close look at the PDF, explaining why PDF was invented and how it evolved into a de facto
standard. Lowagie also lists different versions of the PDF specification to focus on features such as compression and encryption.
(November 22, Book Excerpt)
This chapter excerpt, titled "Development kick-start," walks through installing a blog server and developing a simple blog application using the MetaWebLog API, a widely supported
XML-RPC based Web services protocol that allows retrieving, posting and updating blog entries.
(November 9, Book Excerpt)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
