Re: LDBC driver
- From: Silvio Bierman <sbierman@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 04 Jun 2008 09:27:05 +0200
Lew wrote:
blueparty wrote:http://ldbc.sourceforge.net/
Any experiences, opinions, anything to share ?
I don't see the advantage over JDBC.
They say that with JDBC,# The SQL is different for each databases
# Every JDBC driver behaves differently
# Changes are required for each database
# No time to study all vendor documentation
# No time to test with all databases
However, with JDBC, and especially with JPA, much of the difference between vendors is already abstracted. Also, most products are designed to work with a single database engine; not as many are meant to plug into virtually any RDBMS, and those tend to be written with a generic SQL dialect in the first place.
Where RDBMSes differ the most is in DDL, which is generally outside the scope of the Java program and not such an issue there.
With modern data layers like Hibernate and other JPA solutions, the differences the program does care about are moved off into deployment descriptors. These guys achieve their "independence" by using the same restricted dialect of SQL as you'd use without LDBC if you were to try to be portable.
I can see a niche for it in those few products that are meant to plug into any database, maybe. But for my own work, no thank you. I'll stick with the standard approaches. Last thing I need in my alphabet soup is yet one more layer to go wrong on top of the gazillion layers of abstraction already in place.
I totally agree. My company does supply a system that runs on most major databases (we use PostgreSQL ourselves on our ASP platform but we have customers with private installations using Oracle, SQLServer and MySQL) and as Lew said the relevant differences are in the DDL area mostly.
One extra problem we had to solve was storing UUID values. Some databases have direct support for this data type but the JDBC drivers expose them differently. Some don't support UUIDs directly and in those cases we revert to a binary or plain text representation.
We have solved the differences at the DDL level by generating different database create/drop/etc. scripts using vendor specific XSLT transformations on a generic XML database descriptor.
The PreparedStatement-parameter and ResultSet-getXXX differences we have solved by creating a set of JDBC wrappers for the Connection, PreparedStatement and ResultSet classes that add extra methods like setUUID(...) and getUUID.
Since we already used such wrappers in combination with our connection pool to handle automatic closing of resultsets and statements when connections are returned to the pool (and a facility that allows specification of -1 as the parameter-index on a PreparedStatement and have it do the counting itself) this was a small modification even as an afterthought.
Silvio
.
- References:
- LDBC driver
- From: blueparty
- Re: LDBC driver
- From: Lew
- LDBC driver
- Prev by Date: Re: LDBC driver
- Next by Date: Re: LDBC driver
- Previous by thread: Re: LDBC driver
- Next by thread: Re: LDBC driver
- Index(es):
Relevant Pages
|