High level JDBC Driver

[Pierre Vacher]

Hi all,

I'm currently trying to integrate the Oracle ojdbc.jar driver into my jdbcDriverOOo extension.

While implementing this integration, I realized that it would be possible to provide a universal JDBC driver capable of working with any native JDBC driver.

This certainly adds a software layer between the native JDBC driver and the driver user, but more importantly, it would allow for things that are unthinkable today in terms of JDBC.

And I'm thinking especially of everything that is administration of tables, views,  users and privileges.

Maybe I'm wrong and that's why I'm allowing this topic to be discussed.

[Mark Rotteveel]

On 07/08/2025 14:20, Pierre Vacher wrote:
> I'm currently trying to integrate the Oracle ojdbc.jar driver into my
> jdbcDriverOOo extension.
>
> While implementing this integration, I realized that it would be
> possible to provide a universal JDBC driver capable of working with any
> native JDBC driver.

I think you're mixing up terminology here. A JDBC driver is an
implementation of the JDBC API for a specific database. Sure, there are
JDBC drivers that are decorators around other JDBC drivers, but that
does not make them universal.

I think you're talking about a database-independent library/tool of the
type you're writing, which is not a JDBC driver.

> This certainly adds a software layer between the native JDBC driver and
> the driver user, but more importantly, it would allow for things that
> are unthinkable today in terms of JDBC.
> And I'm thinking especially of everything that is administration of
> tables, views,  users and privileges.
>
> Maybe I'm wrong and that's why I'm allowing this topic to be discussed.

The JDBC API itself _is_ universal, that is, if you use only the JDBC
API, then you shouldn't really need to care about which database you're
talking to: all drivers are expected to conform to the JDBC specification.

However, then there are still a lot of database specifics that are not
abstracted by the JDBC API itself, which you'd need to account for in
your library. Like differences in syntax, etc.

Mark
--
Mark Rotteveel

[Pierre Vacher]

> The JDBC API itself _is_ universal, that is, if you use only the JDBC API

Yes, so we have to say it quickly because if we look at the ResultSet level it's a big mess.

Normally it is possible to make any ResultSet editable. This is what happens when using SQLite under Base with jdbcDriverOOo.

> However, then there are still a lot of database specifics that are not abstracted by the JDBC API itself

There is already a lot of work to be done to make JDBC truly universal regardless of the underlying driver, but in addition it should be possible to offer a higher level API allowing management of elements that are not allowed today (table, user views and roles, privileges, etc.)

[Mark Rotteveel]

On 07/08/2025 15:44, Pierre Vacher wrote:
> > The JDBC API itself _is_ universal, that is, if you use only the JDBC API
>
> Yes, so we have to say it quickly because if we look at the ResultSet
> level it's a big mess.
> Normally it is possible to make any ResultSet editable. This is what
> happens when using SQLite under Base with jdbcDriverOOo.

That is not the case. A result set can only be editable if it was
explicitly requested with CONCUR_UPDATABLE, and the driver is able to
fulfill that request. Otherwise, and by default, a result set is not
updatable.

>> However, then there are still a lot of database specifics that are
> not abstracted by the JDBC API itself
>
> There is already a lot of work to be done to make JDBC truly universal
> regardless of the underlying driver, but in addition it should be
> possible to offer a higher level API allowing management of elements
> that are not allowed today (table, user views and roles, privileges, etc.)

You could try to start a post about that on the jdbc-spec-discuss
mailing list, but I think it is unlikely that will be something that
will be defined as part of JDBC.

Mark
--
Mark Rotteveel