generic jdbc vs individual jdbc drivers?

[maxandersen]

i got a generic jdbc implementation that are capable of downloading java and drivers dynamically based on the connection string.

it all works BUT:

a) tabularis want me to statically define up front things like types and wether schemas are support or not ...is it possible for tabularis to ask that over the connection protocol rather than require that in the .tabularis file?

b) if not possible - I could create driver per known jdbc driver set out there - it will all use the same binary/jdk; just wonderi if possible to have multiple plugins reuse the same binary/scripts or MUST duplicate the binary?

c) is it expected that tabularis is reusing a driver process even after connection url changed? i'm seeing it does not restart the connection so it doesn't get a chance to load another driver.

d) is there a programmatic way to register as the plugin submit only lists 147 repos where I have way past a 1000 repos/orgs ...

[maxandersen]

fwiw here are the databases I currently got wired up this way:

 ┌────────────────────────┬──────────────┬──────────────────────────────────────┐
 │ Scheme                 │ Database     │ Maven GAV                            │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ postgresql / postgres  │ PostgreSQL   │ org.postgresql:postgresql            │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ mysql                  │ MySQL        │ com.mysql:mysql-connector-j          │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ mariadb                │ MariaDB      │ org.mariadb.jdbc:mariadb-java-client │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ oracle                 │ Oracle       │ com.oracle.database.jdbc:ojdbc11     │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ sqlserver              │ SQL Server   │ com.microsoft.sqlserver:mssql-jdbc   │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ db2                    │ DB2          │ com.ibm.db2:jcc                      │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ informix               │ Informix     │ com.ibm.informix:jdbc                │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ firebird / firebirdsql │ Firebird     │ org.firebirdsql.jdbc:jaybird         │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ h2                     │ H2           │ com.h2database:h2                    │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ hsqldb                 │ HSQLDB       │ org.hsqldb:hsqldb                    │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ derby                  │ Apache Derby │ org.apache.derby:derby               │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ sqlite                 │ SQLite       │ org.xerial:sqlite-jdbc               │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ duckdb                 │ DuckDB       │ org.duckdb:duckdb_jdbc               │
 ├────────────────────────┼──────────────┼──────────────────────────────────────┤
 │ sap                    │ SAP HANA     │ com.sap.cloud.db.jdbc:ngdbc          │
 └────────────────────────┴──────────────┴──────────────────────────────────────┘

[debba]

This is a really interesting use case. A generic JDBC bridge could give Tabularis broad database coverage without duplicating a lot of work, so we are very open to exploring what changes would be needed to support it properly.

a) Right now, capabilities and data types are defined statically in the manifest. Tabularis reads them before opening a connection because they control the connection form and other parts of the UI. We currently do not have an RPC for discovering capabilities or data types dynamically from a connection.

That said, this is not something we consider set in stone. A generic JDBC driver is a strong use case for dynamic metadata, and we would be happy to evaluate changes to the protocol and the application to make it possible.

Before opening a PR, I suggest joining our Discord server. We can discuss the design together, understand what your implementation needs, and agree on an approach before you spend time coding. This should help us avoid unnecessary work or changes that would later need to be redesigned.

Once we agree on the direction, you are very welcome to open a PR on the Tabularis repository. I will be happy to follow the work, review it, and help with any changes needed on the Tabularis side.

b) Plugin packages are currently self-contained. There is no officially supported way for multiple installed plugins to share an executable or dependency directory. You can share the source code and build pipeline, but each published plugin package must currently include its own manifest and executable.

For this reason, a single generic JDBC plugin would probably be the better solution if we add dynamic metadata support. However, we are also open to discussing whether the packaging model needs improvements for this kind of use case.

c) Yes, reusing the process is intentional. Tabularis starts one process per plugin driver and reuses it across connections. It does not restart the process when the connection URL changes.

Every JSON-RPC request includes the current ConnectionParams, so the plugin should select or recreate its JDBC connection based on those values. If it caches connections only by connection_id, it may keep using a stale connection because the ID remains the same when a saved connection is edited.

We can look at this together as well. If the current lifecycle makes a generic JDBC implementation difficult, we can consider explicit connection lifecycle methods or other protocol changes.

d) The repository picker limitation should not block you. Tabularium supports publishing from CI using a publisher token and POST /api/publish/:slug:

https://docs.tabularium.wiki/authors/publish-push/

We should still investigate why the submission page only shows 147 repositories for your account, and we will be happy to help you get the plugin published.

If you share the generic JDBC plugin repository with us, we can take a look before discussing the next steps on Discord. We are very interested in this and fully available to work with you on finding the right solution.

[maxandersen]

my current experiment is in https://github.com/tabularis-jdbc/ (i created org for it as i needed smaller repo count :)

https://github.com/tabularis-jdbc/tabularis-jdbc is the main repo - its ultra simple and not in its final form :)

But that repo has the code that then generates all the other specific jdbc projects to "please" current tabularis.

What would be great is if I could make a tabularis plugin bundle that can provide multiple connection types - then I can make one executable/script that cover all of them without having it all be one generic one.

I'll find time and join on discord :)