Re: Non-ORM layers over JDBC

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.

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. If you
are used to SQL, it make take a little getting used to because HQL is more
abstract than SQL. It's like making a jump from C to Java, more abstraction,
less code, less raw power.

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.

ORM falls down badly for two things: 1) OLAP style database work and 2) Batch
processing. OLAP depends way too much on specific database facilities to
make things fast, which Hibernate can't take advantage of. Batch processing
chokes because Hibernate will cache too much because it is trying to optimize
OLTP style interactions.

David Clark

On Monday 24 March 2008, Craig Ringer wrote:
> Hi all
>
> I'm fairly new to Java (sorry!) and struggling with the database access
> area. My PostgreSQL database is fairy complex and significant parts of
> its user interface are through stored procedures etc. I've been looking
> into Hibernate / Hibernate EntityManager and other EJB3-compatible
> tools, but they all seem to be oriented toward database-independence and
> using the DB as a dumb storage engine. They even implement their own
> outer joins (!) and other core DB functionality. Currently I'm trying to
> figure out why a "SELECT c FROM customer c;" (Hibernate-style) is
> introducing a WHERE clause for on the customer's bank_id when executed
> ... so I'm not impressed so far.
>
> However, I've also looked at raw JDBC code, and it seems to be very
> verbose with a lot of manual data conversion and little language
> integration.
>
> I'm somewhat spoiled by having come from C++ with TrollTech's Qt, a
> toolkit so good that it makes C++ not only worth using but even nice. It
> has SQL-enabled widgets with a lot of programmer control, and a very
> nice and well integrated SQL interface that doesn't impose too many
> weird limits or force you to work around your SQL access layer to do
> simple things. It makes good use of variant types and conversion
> operators to minimise the amount of manual type wrangling the programmer
> has to do.
>
> I've done a fair bit of searching but haven't found any sort of JDBC
> over-layer that integrates database access into the Java language a bit
> better but without all the ORM database-independence stuff.
>
> What do people here use? Just use the JDBC directly? Use an ORM layer
> even though you just target PostgreSQL and work around its limitations
> and quirks? Use a different ORM layer without weird limitations and
> quirks? Some other tool I haven't been able to find out about?
>
> I'm writing a pretty ordinary desktop app, but I was really hoping to
> avoid writing vast amounts of database interface code even for the
> simpler parts of the interface, as appears to be necessary with direct
> JDBC use.
>
> Comments on what you're using or would like to have used would be very
> much appreciated.
>
> --
> Craig Ringer
>
> -
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc