Re: Non-ORM layers over JDBC - Mailing list pgsql-jdbc
From | David Clark |
---|---|
Subject | Re: Non-ORM layers over JDBC |
Date | |
Msg-id | 200803240953.11979.davidclark@tx.rr.com Whole thread Raw |
In response to | Non-ORM layers over JDBC (Craig Ringer <craig@postnewspapers.com.au>) |
Responses |
Re: Non-ORM layers over JDBC
|
List | pgsql-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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
pgsql-jdbc by date: