Skip site navigation (1) Skip section navigation (2)

Re: Non-ORM layers over JDBC

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: David Clark <davidclark(at)tx(dot)rr(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Non-ORM layers over JDBC
Date: 2008-03-24 17:40:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
David Clark wrote:
> If you want JDBC access that is more closely integrated into the language I 
> would suggest using Groovy.  It REALLY simplifies JDBC access because of 
> Groovy's dynamic typing, which is basically the same thing as using variant 
> data types in C++, at least syntactically.  Groovy's way of executing JDBC's 
> statements is also much easier to use.  Groovy compiles to Java class files 
> and the JVM doesn't know the difference.  The groovy runtime/library is just 
> a jar file that you stick on your classpath.
This app needs to be maintainable by others and rather future-proof, so 
I'm a little leery of Groovy as something that's still a bit "out there" 
in Java land. I suspect that the best option here is plain old JDBC. 
Thankfully the app won't need too much SQL with highly variable WHERE 
clauses etc, so it shouldn't be too bad.

I've just spent some time looking over the website for iBatis, though, 
and I'd be interested in hearing if anybody has any experience with / 
comments about it. It looks closer to what I'm after than hibernate and 
friends do.
> ORM for me works really well in OLTP situations.  If I am doing pure OLTP I 
> rarely need to go outside of my ORM access layer, which is Hibernate.  
> Hibernate's query language (HQL) has lots of features to make writing SQL 
> queries easier and lots of features to minimize performance problems.
Yep, it seems pretty attractive for that sort of role - but not much use 
for a 2 tier database app.

I'm trying to keep middleware application servers etc out of the picture 
to reduce the number of required components - simplify maintainance and 
administration, reduce dependencies, etc.

If I wasn't taking that approach I'd probably just build it in C++ with Qt .
> If you have lots of screens where users are basically building up sql queries, 
> using forms, then Hibernate's query by criteria makes this easy because you 
> are not longer manually building up SQL (or HQL) queries by hand (which is 
> really error prone).  All of my complicated search screens use this feature 
> of Hibernate.
Yep, I truly detest the "Hmm, do I need an AND here" comma-and-keyword 
juggling sort of low level syntax fiddling that's required for building 
up SQL queries programatically. The query languages offered by things 
like Hibernate look nice for that,  but Hibernate its self seems to be 
designed for use with middleware servers to the detriment of most other 
things. I haven't found much good said about its use in "direct" 
database apps, though it's clearly great for use in an appserver.

I've also found it more difficult than I thought to plug Hibernate 
queries directly into Swing for use as a data model, providing efficient 
database fetching etc. Then again, my Java is rather limited as is my 
Swing experience, so I might just be doing it wrong.

Craig Ringer

In response to


pgsql-jdbc by date

Next:From: Joao Rui LealDate: 2008-03-24 17:58:06
Subject: Deadlock while using getNotifications() and Statement.executeQuery()
Previous:From: Woody WoodringDate: 2008-03-24 15:57:18
Subject: Re: JDBC rewriting a bad query?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group