But I don't know if it is reliable enough across JDBC drivers, I don't have
that level of SQL/JDBC experience.
Ahhh! I just saw (looking for how to get the JDBC Connection), that the
DatabaseMetaData is already abstracted out in class Meta. For me, that is
good enough for now, as I can always make the check before doing a
createTable and not rely on "ifNotExists". No action required from you, for
For @Support annotation; If I understand it correctly, it is intended for
when you use the JOOQ data modeling tooling. In my case, everything is
runtime (Table<Record>, and no known types at compile time) and Polygene
has its own modeling design (close to DDD) with Entity, Association,
ManyAssociation and NamedAssociation and quite well manage to hide the
implementation details in the underlying store. The upside is that no JOOQ
details is visible to our users, and I can control exactly what method
calls into JOOQ that is performed (quite few).
For reference, we currently support; 'Cassandra', 'File', 'Geode',
'Hazelcast', 'JClouds', 'Jdbm', 'LevelDB', 'Memory', 'MongoDB', 'Java
Preferences', 'Redis', 'Riak' and a SQL Key/Value store. This JOOQ-backed
SQL Entity Store is strategically important to tackle enterprise
I agree that definition of "features" are difficult and might be
counter-productive. Perhaps it is enough to get hold of the JDBC
Connection, getDatabaseMetaData and check the many supportsXyz() methods in
there. Is there a way to get hold of the current connection? I think I can
only do acquire() on the ThreadLocalConnectionProvider but Reflection on
the ThreadLocalTransactionProvider, but that is nasty and would like to
avoid if there is a better way.
All-in-all, there is not much "meat" left in this thread. I am quite happy
On Friday, October 27, 2017 at 12:05:52 AM UTC+8, Lukas Eder wrote:
> But I don't know if it is reliable enough across JDBC drivers, I don't
> have that level of SQL/JDBC experience.
Well, for starters, that DatabaseMetaData API is really not reliable,
unfortunately. The jOOQ code generator does not rely on it to reverse
engineer your database, we run our own queries against each databases'
Also, behind the scenes, DatabaseMetaData runs a query (how else would it
fetch the tables?), but that query is not governed by any of jOOQ's
execution lifecycles, which raises many new questions about how this
interaction would be perceived by jOOQ API users.
> good enough for now, as I can always make the check before doing a
> createTable and not rely on "ifNotExists". No action required from you, for
> _my_ benefit.
True, sorry, I should have thought of this. You can manually do that check
on your side.
> For @Support annotation; If I understand it correctly, it is intended for
> when you use the JOOQ data modeling tooling.
I'm not sure what you mean by data modeling tooling. The code generator? In
that case, no: The @Support annotation annotates the DSL API to tell users
which SQL clauses are available in which SQL dialects. For instance, you
could see that createTableIfNotExists is available for these dialects:
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].