profile
viewpoint
Lukas Eder lukaseder Data Geekery GmbH St. Gallen https://www.jooq.org SQL is a device whose mystery is only exceeded by its power

Chrriis/RRDiagram 114

Generate railroad diagrams from code or BNF, generate BNF from code

verhas/fluflu 65

Fluent Api Creator

lukaseder/silly-metrics 8

Silly metrics is a bunch of scripts that provide you with silly and mostly useless metrics about your Java project

lukaseder/awesome-annotation-processing 2

A curated list of resources related to the Java annotation processoring API (JSR 269)

lukaseder/h2database 1

H2 is an embeddable RDBMS written in Java.

lukaseder/examples-orms 0

Sample uses of CockroachDB with popular ORMs

lukaseder/jooq-basic-sample 0

A basic example of using jOOQ with CockroachDB

lukaseder/jOOQ-mcve 0

A simple example project that can be used to create MCVE's to report jOOQ issues

lukaseder/JooqTest 0

Simple application to test Java Object Oriented Querying (JOOQ)

issue commentjOOQ/jOOQ

Deprecate SQLDialect#supports(Collection<SQLDialect>) method

Yes please.

Am Donnerstag, 27. Februar 2020 schrieb Knut Wannheden < notifications@github.com>:

Is this something worth adding to the refaster templates?

I also thought about this. Somehow I doubt anybody is using this method, but we could of course offer a migration anyway.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jOOQ/jOOQ/issues/9882?email_source=notifications&email_token=AAFTLALJXOZTQBFBQTLAQ33RE7B5JA5CNFSM4K4BPA3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENEQFNI#issuecomment-591987381, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFTLAJM7HUDFYDNT2JK4ALRE7B5JANCNFSM4K4BPA3A .

knutwannheden

comment created time in 10 hours

CommitCommentEvent

issue closedjOOQ/jOOQ

Change Pro annotation retention to class

For tooling like the API diff (https://github.com/jOOQ/jOOQ/issues/8254), we could profit from having a Pro annotation with CLASS retention rather than with SOURCE retention. There are only few things annotated with this annotation, so the overhead should be negligible.

closed time in 11 hours

lukaseder

issue commentjOOQ/jOOQ

Change Pro annotation retention to class

Fixed in 3.14.0. Backport scheduled for 3.13.2 (#9892) and 3.12.5 (#9893)

lukaseder

comment created time in 11 hours

issue openedjOOQ/jOOQ

Change Pro annotation retention to class

For tooling like the API diff (https://github.com/jOOQ/jOOQ/issues/8254), we could profit from having a Pro annotation with CLASS retention rather than with SOURCE retention. There are only few things annotated with this annotation, so the overhead should be negligible.

created time in 11 hours

issue commentjOOQ/jOOQ

Publish an API version diff in the manual

The @Pro annotation was only added in jOOQ 3.12, and with SOURCE retention. Hence, we cannot easily process it in this report.

lukaseder

comment created time in 11 hours

issue closedjOOQ/jOOQ

Compilation error in generated DAOs

Hello I am trying to upgrade our jOOQ version from 3.11.11 to 3.12.3 and I get an issue at compilation time.

I have seen some similar issues like this one: https://github.com/jOOQ/jOOQ/issues/7068 But the primary key is not a composite type

Here is a sample of a table with generates a wrong DAO:

 CREATE TABLE "SCHEMA"."CONTRAT" (
    "ID" NUMBER(19,0) NOT NULL ENABLE,
    ...,
    PRIMARY KEY ("ID")
) 

Expected behavior and actual behavior:

Maven code generation generates a protected method inside a DAO

   /**
     * {@inheritDoc}
     */
    @Override
    protected BigInteger getId(mypackages.jooq.tables.pojos.Contrat object) {
        return object.getId();
    }

Thus it does not compile, the error is "attempting to assign weaker access privileges ('protected'); was 'public"

Expected behavior is: the method should be public I guess

Steps to reproduce the problem (if possible, create an MCVE: https://github.com/jOOQ/jOOQ-mcve):

I am actually trying, but little time at the moment

Versions:

  • jOOQ: Pro 3.12.3
  • Java: 11
  • Database (include vendor): Oracle 12c
  • JDBC Driver (include name if inofficial driver): Oracle OJDBC 19.3

closed time in 12 hours

callain

issue commentjOOQ/jOOQ

Compilation error in generated DAOs

Thank you very much for your report. It seems that you're using an older code generator version than the runtime library version.

In jOOQ 3.12, we pulled up the DAOImpl.getId() method (which was protected) to DAO: https://github.com/jOOQ/jOOQ/issues/7874. This means that older code needs to be re-generated with a code generator of version 3.12 as well.

I hope this helps

callain

comment created time in 12 hours

issue commentjOOQ/jOOQ

Add support for DSL.execute() in Oracle

Thank you very much for your report.

As of jOOQ 3.13, DSL.execute() is only supported for the PostgreSQL dialect, not for Oracle yet. We should definitely add support for Oracle as well, of course, to produce an EXECUTE IMMEDIATE statement.

mnisius

comment created time in 12 hours

CommitCommentEvent

issue commentjOOQ/jOOQ

Translate SQL Server WITH (ROWLOCK) clauses to corresponding FOR UPDATE

Thank you very much for your request. This is currently not possible, I'm afraid.

A similar translation idea in the opposite direction is this: https://github.com/jOOQ/jOOQ/issues/8844

We should definitely consider this. Especially when there is only one table involved, the translation might be straightforward.

luhui0928

comment created time in 12 hours

issue commentjOOQ/jOOQ

Deprecate SQLDialect#supports(Collection<SQLDialect>) method

Is this something worth adding to the refaster templates?

knutwannheden

comment created time in 12 hours

push eventjOOQ/jOOQ

Lukas Eder

commit sha cf5ecafa7b73171d2176d4827500ffcb08dc4cb9

[jOOQ/jOOQ#8805] Fix parser behaviour for OVERLAY() in DB2

view details

push time in 12 hours

issue commentjOOQ/jOOQ

Support OVERLAY() function

For the record, the SQL standard disagrees with DB2:

image

knutwannheden

comment created time in 12 hours

issue commentjOOQ/jOOQ

Support OVERLAY() function

LUW link here: https://www.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.sql.ref.doc/doc/r0050492.html

That default makes no sense :-/ but oh well. I guess we should fix the parser too, then. When the parse dialect is DB2, it would be better to generate an explicit length of 1, then.

knutwannheden

comment created time in 12 hours

issue closedjOOQ/jOOQ

Add support for native ILIKE in H2

H2 supports … [ NOT ] ILIKE … [ ESCAPE … ] condition since version 1.4.194: https://h2database.com/html/grammar.html#condition_right_hand_side For older versions cast of the left operand to VARCHAR_IGNORECASE can be used (if such versions are still supported by jOOQ).

jOOQ currently generates an inefficient and not fully compatible replacement code with the LOWER function. Such code that can't properly handle some national letters.

CREATE TABLE TEST(A VARCHAR(1), B VARCHAR(1)) AS VALUES ('I', 'ı');
SELECT A ILIKE B, LOWER(A) LIKE LOWER(B) FROM TEST;
> TRUE FALSE

closed time in 12 hours

katzyn

push eventjOOQ/jOOQ

Lukas Eder

commit sha b95cc5fde8fadbb872c788d9c0b3ce0e7779160f

[jOOQ/jOOQ#9889] Add support for native ILIKE in H2

view details

push time in 12 hours

issue commentjOOQ/jOOQ

Add support for native ILIKE in H2

Thanks a lot for your feature request. Great to know, we hadn't noticed this improvement in 1.4.194. Definitely makes sense to generate native support

(if such versions are still supported by jOOQ)

We're currently not supporting old versions of H2. We might, in the future.

jOOQ currently generates an inefficient and not fully compatible replacement code with the LOWER function. Such code that can't properly handle some national letters.

Yes, that's a known limitation of the current approach. It could be worked around using collations explicitly, but we're not doing that yet.

katzyn

comment created time in 12 hours

issue commentjOOQ/jOOQ

Support parsing some PostgreSQL specific operators

The matching operators have been supported now. I'll leave this issue open, as we might want to support other operators as well

lukaseder

comment created time in 12 hours

push eventjOOQ/jOOQ

Lukas Eder

commit sha 7301ef77642dfa54dd63f819d53986bab9960550

[jOOQ/jOOQ#9888] Support parsing some PostgreSQL specific operators

view details

push time in 13 hours

issue commentjOOQ/jOOQ

Support parsing some PostgreSQL specific operators

How to identify an operator part in PostgreSQL:

    boolean isOperatorPart(char character) {
        // Obtain all distinct, built-in PostgreSQL operator characters:
        // select distinct regexp_split_to_table(oprname, '') from pg_catalog.pg_operator order by 1;
        switch (character) {
            case '!':
            case '#':
            case '%':
            case '&':
            case '*':
            case '+':
            case '-':
            case '/':
            case ':':
            case '<':
            case '=':
            case '>':
            case '?':
            case '@':
            case '^':
            case '|':
            case '~':
                return true;
        }

        return false;
    }
lukaseder

comment created time in 13 hours

issue commentjOOQ/jOOQ

Support parsing some PostgreSQL specific operators

These operators can also get in the way of the DELIMITER feature, when we specify e.g.

DELIMITER ~~
lukaseder

comment created time in 13 hours

issue commentjOOQ/jOOQ

Support parsing some PostgreSQL specific operators

To properly disambiguate such operators (e.g. prevent trying to parse ~~ before ~~*, we would have to either

  • re-order parser logic (very complicated and difficult to get right)
  • introduce new parser infrastructure like parseKeywordIf() but parseOperatorIf()
lukaseder

comment created time in 13 hours

issue openedjOOQ/jOOQ

Support parsing some PostgreSQL specific operators

PostgreSQL has a large amount of ASCII operators that correspond to standard SQL operators or function calls. Some of these operators may be popular in idiomatic PostgreSQL usage, and may be produced by default in generated DDL scripts (e.g. for DEFAULT expressions, CHECK constraints, etc.).

We should support at least these operators (list may be enhanced):

  • [ ] Matching operators (see https://www.postgresql.org/docs/current/functions-matching.html)
    • [ ] ~~ corresponding to LIKE
    • [ ] ~~* corresponding to ILIKE
    • [ ] !~~ corresponding to LIKE
    • [ ] !~~* corresponding to LIKE
    • [ ] ~ corresponding to REGEXP_LIKE (not natively supported in PG)
    • [ ] ~* corresponding to REGEXP_ILIKE (not natively supported in PG)
    • [ ] !~ corresponding to NOT REGEXP_LIKE (not natively supported in PG)
    • [ ] !~* corresponding to NOT REGEXP_ILIKE (not natively supported in PG)

created time in 14 hours

issue closedjOOQ/jOOQ

Generate code based on greenplum schema

Hey,

Is it possible to use the existing postgres support to connect to GP and generate classes?

closed time in 14 hours

varsanyid

issue commentjOOQ/jOOQ

Generate code based on greenplum schema

Thank you very much for your message. We currently do not support Greenplum officially (see https://github.com/jOOQ/jOOQ/issues/4700).

It might be possible to work with the existing PostgreSQL support, but as we have seen with a lot of users who had been using e.g. Redshift or CockroachDB with the PostgreSQL, the devil is in the details, when some code generator query doesn't work on the respective "PostgreSQL compatible" product.

There are a few more vendor agnostic options in the code generator, such as the JDBCDatabase, which uses JDBC DatabaseMetaData behind the scenes to reverse engineer your schema. There are also:

  • XMLDatabase, which reverse engineers an XML representation of your schema: https://www.jooq.org/doc/latest/manual/code-generation/codegen-xml/
  • DDLDatabase, which parses your DDL scripts and interprets them without an actual DB connection: https://www.jooq.org/doc/latest/manual/code-generation/codegen-ddl/
  • LiquibaseDatabase, which interprets your Liquibase migration files and produces code from that: https://www.jooq.org/doc/latest/manual/code-generation/codegen-liquibase/

I hope this helps

varsanyid

comment created time in 14 hours

issue commentjOOQ/jOOQ

Publish an API diff in the manual using japicmp

I had noticed that too. Was going to investigate tomorrow. There are a few "ignorable" binary incompatibilities that are currently not detected.

Am Mittwoch, 26. Februar 2020 schrieb Knut Wannheden < notifications@github.com>:

Cool! Shouldn't in https://www.jooq.org/api-diff/3.12-3.13 the AlterSequenceStep#restart() methods be considered pulledup? I suppose the "problem" is that the type where the methods are defined ( AlterSequenceFlagsStep), wasn't part of 3.12 yet.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/jOOQ/jOOQ/issues/8254?email_source=notifications&email_token=AAFTLAOQ4ZO4FS24YOSQ3S3RE2DAVA5CNFSM4GSKLPC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENAVNGI#issuecomment-591484569, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFTLAMCE7P2PMUVHWDQFOTRE2DAVANCNFSM4GSKLPCQ .

lukaseder

comment created time in a day

issue commentjOOQ/jOOQ

Publish an API diff in the manual using japicmp

There's now an overview page as well, where all the other pages are linked from: https://www.jooq.org/api-diff

I like where this is going. Still a lot to polish, but this will be very useful!

lukaseder

comment created time in a day

issue commentjOOQ/jOOQ

Publish an API diff in the manual using japicmp

This is taking shape. For example: https://www.jooq.org/api-diff/3.12-3.13

TODOs:

  • [ ] Fix package headers
  • [ ] Nicer formatting
  • [ ] Fix <init> formatting (constructor)
  • [ ] Distinguish between static and instance methods
  • [ ] Some icons like in https://javaalmanac.io/jdk/15/apidiff/8/
  • [ ] Javadoc links for methods
  • [ ] Ignore some additional binary incompatibilities:
    • [x] Ignore method return types
    • [ ] Discover when methods were pulled up (don't show them as removed, such as Key.getName())
  • [ ] Possibly handle nested classes, like DiffCLI$Args (?)
  • [ ] Show deprecation changes
  • [ ] Ignore @Internal stuff
  • [ ] Display @Support annotation changes
lukaseder

comment created time in a day

issue commentjOOQ/jOOQ

Publish an API diff in the manual using japicmp

Yes

lukaseder

comment created time in 2 days

issue commentjOOQ/jOOQ

Publish an API diff in the manual using japicmp

This little script:

public class ApiDiff {

    final String oldVersion;
    final String newVersion;
    final File oldJarFile;
    final File newJarFile;

    public ApiDiff(String oldVersion, String newVersion) {
        this.oldVersion = oldVersion;
        this.newVersion = newVersion;

        this.oldJarFile = lookupJarFile(oldVersion);
        this.newJarFile = lookupJarFile(newVersion);
    }

    private File lookupJarFile(String version) {
        return new File("C:/users/lukas/.m2/repository/org/jooq/pro/jooq/" + version + "/jooq-" + version + ".jar");
    }

    private void run() throws Exception {
        try (JarFile j1 = new JarFile(oldJarFile);
             JarFile j2 = new JarFile(newJarFile)) {

            Iterator<ClassNode> i1 = classes(j1);
            Iterator<ClassNode> i2 = classes(j2);

            append(i1, i2, CLASS_COMP,
                c -> System.out.println("+" + c.name),
                c -> System.out.println("-" + c.name),
                (c1, c2) -> {
                    AtomicBoolean b = new AtomicBoolean();
                    BiConsumer<MethodNode, String> r = (m, prefix) -> {
                        if (b.compareAndSet(false, true))
                            System.out.println(" " + c1.name);
                        
                        System.out.println(prefix + m.name + (m.signature != null ? " " + m.signature : ""));
                    };
                    
                    append(methods(c1), methods(c2), METHOD_COMP,
                        m -> r.accept(m, "    +"),
                        m -> r.accept(m, "    -"),
                        (m1, m2) -> {}
                    );
                }
            );
        }
    }

    private final <N> void append(
        Iterator<? extends N> i1,
        Iterator<? extends N> i2,
        Comparator<? super N> comp,
        Consumer<N> create,
        Consumer<N> drop,
        BiConsumer<N, N> merge
    ) {
        N n1 = null;
        N n2 = null;

        for (;;) {
            if (n1 == null && i1.hasNext())
                n1 = i1.next();

            if (n2 == null && i2.hasNext())
                n2 = i2.next();

            if (n1 == null && n2 == null)
                break;

            int c = n1 == null
                  ? 1
                  : n2 == null
                  ? -1
                  : comp.compare(n1, n2);

            if (c < 0) {
                if (drop != null)
                    drop.accept(n1);

                n1 = null;
            }
            else if (c > 0) {
                if (create != null)
                    create.accept(n2);

                n2 = null;
            }
            else {
                if (merge != null)
                    merge.accept(n1, n2);

                n1 = n2 = null;
            }
        }
    }
    
    private static final Comparator<MethodNode> METHOD_COMP = Comparator
        .<MethodNode, String>comparing(m -> m.name)
        .thenComparing(m -> m.signature == null ? "" : m.signature);
    
    private static final Comparator<ClassNode> CLASS_COMP = Comparator.comparing(c -> c.name);
    
    private Iterator<MethodNode> methods(ClassNode n) {
        return n.methods
            .stream()
            .filter(m -> (m.access & Opcodes.ACC_PUBLIC) != 0)
            .sorted(METHOD_COMP)
            .iterator();
    }

    private Iterator<ClassNode> classes(JarFile jar) {
        return jar.stream()
            .filter(e -> e.getName().endsWith(".class"))
            .map(e -> new ClassReader(readEntry(jar, e)))
            .map(c -> {
                ClassNode node = new ClassNode();
                c.accept(node, 0);
                return node;
            })
            .filter(c -> (c.access & Opcodes.ACC_PUBLIC) != 0)
            .sorted(CLASS_COMP)
            .iterator();
    }

    private byte[] readEntry(JarFile jar, JarEntry e) {
        try (InputStream is = jar.getInputStream(e)) {
            return IOUtils.toByteArray(is);
        }
        catch (IOException ex) {
            throw new RuntimeException(ex);
        }
    }

    public static void main(String[] args) throws Exception {
        new ApiDiff("3.12.3", "3.13.1").run();
    }
}

Produces this output:

+org/jooq/AlterSequenceFlagsStep
-org/jooq/AlterSequenceRestartStep
 org/jooq/AlterSequenceStep
    -restart
    -restartWith (Lorg/jooq/Field<+TT;>;)Lorg/jooq/AlterSequenceFinalStep;
    -restartWith (TT;)Lorg/jooq/AlterSequenceFinalStep;
+org/jooq/AlterTableAddStep
+org/jooq/AlterTableAlterConstraintStep
 org/jooq/AlterTableAlterStep
    +dropDefault
    +setDefault (Lorg/jooq/Field<TT;>;)Lorg/jooq/AlterTableFinalStep;
    +setDefault (TT;)Lorg/jooq/AlterTableFinalStep;
 org/jooq/AlterTableStep
    +add (Ljava/lang/String;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableAddStep;
    -add (Ljava/lang/String;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableFinalStep;
    +add (Ljava/util/Collection<+Lorg/jooq/FieldOrConstraint;>;)Lorg/jooq/AlterTableAddStep;
    -add (Ljava/util/Collection<+Lorg/jooq/FieldOrConstraint;>;)Lorg/jooq/AlterTableFinalStep;
    +add (Lorg/jooq/Field<*>;)Lorg/jooq/AlterTableAddStep;
    -add (Lorg/jooq/Field<*>;)Lorg/jooq/AlterTableFinalStep;
    +add (Lorg/jooq/Name;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableAddStep;
    -add (Lorg/jooq/Name;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableFinalStep;
    +add <T:Ljava/lang/Object;>(Lorg/jooq/Field<TT;>;Lorg/jooq/DataType<TT;>;)Lorg/jooq/AlterTableAddStep;
    -add <T:Ljava/lang/Object;>(Lorg/jooq/Field<TT;>;Lorg/jooq/DataType<TT;>;)Lorg/jooq/AlterTableFinalStep;
    +addColumn (Ljava/lang/String;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableAddStep;
    -addColumn (Ljava/lang/String;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableFinalStep;
    +addColumn (Lorg/jooq/Field<*>;)Lorg/jooq/AlterTableAddStep;
    -addColumn (Lorg/jooq/Field<*>;)Lorg/jooq/AlterTableFinalStep;
    +addColumn (Lorg/jooq/Name;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableAddStep;
    -addColumn (Lorg/jooq/Name;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableFinalStep;
    +addColumn <T:Ljava/lang/Object;>(Lorg/jooq/Field<TT;>;Lorg/jooq/DataType<TT;>;)Lorg/jooq/AlterTableAddStep;
    -addColumn <T:Ljava/lang/Object;>(Lorg/jooq/Field<TT;>;Lorg/jooq/DataType<TT;>;)Lorg/jooq/AlterTableFinalStep;
    +addColumnIfNotExists (Ljava/lang/String;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableAddStep;
    -addColumnIfNotExists (Ljava/lang/String;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableFinalStep;
    +addColumnIfNotExists (Lorg/jooq/Field<*>;)Lorg/jooq/AlterTableAddStep;
    -addColumnIfNotExists (Lorg/jooq/Field<*>;)Lorg/jooq/AlterTableFinalStep;
    +addColumnIfNotExists (Lorg/jooq/Name;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableAddStep;
    -addColumnIfNotExists (Lorg/jooq/Name;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableFinalStep;
    +addColumnIfNotExists <T:Ljava/lang/Object;>(Lorg/jooq/Field<TT;>;Lorg/jooq/DataType<TT;>;)Lorg/jooq/AlterTableAddStep;
    -addColumnIfNotExists <T:Ljava/lang/Object;>(Lorg/jooq/Field<TT;>;Lorg/jooq/DataType<TT;>;)Lorg/jooq/AlterTableFinalStep;
    +addIfNotExists (Ljava/lang/String;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableAddStep;
    -addIfNotExists (Ljava/lang/String;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableFinalStep;
    +addIfNotExists (Lorg/jooq/Field<*>;)Lorg/jooq/AlterTableAddStep;
    -addIfNotExists (Lorg/jooq/Field<*>;)Lorg/jooq/AlterTableFinalStep;
    +addIfNotExists (Lorg/jooq/Name;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableAddStep;
    -addIfNotExists (Lorg/jooq/Name;Lorg/jooq/DataType<*>;)Lorg/jooq/AlterTableFinalStep;
    +addIfNotExists <T:Ljava/lang/Object;>(Lorg/jooq/Field<TT;>;Lorg/jooq/DataType<TT;>;)Lorg/jooq/AlterTableAddStep;
    -addIfNotExists <T:Ljava/lang/Object;>(Lorg/jooq/Field<TT;>;Lorg/jooq/DataType<TT;>;)Lorg/jooq/AlterTableFinalStep;
    +alter
    +alterConstraint
    +alterConstraint
    +alterConstraint
    +dropConstraintIfExists
    +dropConstraintIfExists
    +dropConstraintIfExists
    +dropIfExists
    +dropUnique
    +dropUnique
    +dropUnique
+org/jooq/AlterTypeFinalStep
+org/jooq/AlterTypeRenameValueToStep
+org/jooq/AlterTypeStep
 org/jooq/Batch
    +executeAsync ()Ljava/util/concurrent/CompletionStage<[I>;
    +executeAsync (Ljava/util/concurrent/Executor;)Ljava/util/concurrent/CompletionStage<[I>;
+org/jooq/Check
 org/jooq/Configuration
    +derive
    +derive
    +derive
    +interpreterConnectionProvider
    +migrationListenerProviders
    +set
    +set
    +set
    +systemConnectionProvider
    +versionProvider
+org/jooq/ConstraintEnforcementStep
 org/jooq/ConstraintTypeStep
    +primaryKey ([Lorg/jooq/Field<*>;)Lorg/jooq/ConstraintEnforcementStep;
    -primaryKey ([Lorg/jooq/Field<*>;)Lorg/jooq/ConstraintFinalStep;
    +unique ([Lorg/jooq/Field<*>;)Lorg/jooq/ConstraintEnforcementStep;
    -unique ([Lorg/jooq/Field<*>;)Lorg/jooq/ConstraintFinalStep;
 org/jooq/DDLExportConfiguration
    +createIndexIfNotExists
    +createIndexIfNotExists
    +createOrReplaceView
    +createOrReplaceView
    +createSequenceIfNotExists
    +createSequenceIfNotExists
    +createViewIfNotExists
    +createViewIfNotExists
    +defaultSequenceFlags
    +defaultSequenceFlags
    +respectCatalogOrder
    +respectCatalogOrder
    +respectColumnOrder
    +respectColumnOrder
    +respectConstraintOrder
    +respectConstraintOrder
    +respectIndexOrder
    +respectIndexOrder
    +respectSchemaOrder
    +respectSchemaOrder
    +respectSequenceOrder
    +respectSequenceOrder
    +respectTableOrder
    +respectTableOrder
 org/jooq/DSLContext
    +alterType
    +alterType
    +createTemporaryTableIfNotExists
    +createTemporaryTableIfNotExists
    +createTemporaryTableIfNotExists (Lorg/jooq/Table<*>;)Lorg/jooq/CreateTableColumnStep;
    +delete <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteUsingStep<TR;>;
    -delete <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteWhereStep<TR;>;
    +deleteFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteUsingStep<TR;>;
    -deleteFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteWhereStep<TR;>;
    +dropTemporaryTableIfExists
    +dropTemporaryTableIfExists
    +dropTemporaryTableIfExists (Lorg/jooq/Table<*>;)Lorg/jooq/DropTableStep;
    +meta
    +meta
    +migrateTo
    +selectFrom (Ljava/lang/String;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Ljava/lang/String;[Ljava/lang/Object;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Ljava/lang/String;[Lorg/jooq/QueryPart;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Lorg/jooq/Name;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Lorg/jooq/SQL;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;[Ljava/lang/Object;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;[Lorg/jooq/QueryPart;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Name;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Lorg/jooq/SQL;)Lorg/jooq/SelectWhereStep<TR;>;
    +set (Lorg/jooq/Name;Lorg/jooq/Param<*>;)Lorg/jooq/RowCountQuery;
    +version
 org/jooq/DataType
    +isInteger
 org/jooq/DeleteQuery
    +addUsing (Ljava/util/Collection<+Lorg/jooq/TableLike<*>;>;)V
    +addUsing (Lorg/jooq/TableLike<*>;)V
    +addUsing ([Lorg/jooq/TableLike<*>;)V
+org/jooq/DeleteUsingStep
+org/jooq/DiffCLI
+org/jooq/DiffCLI$Args
+org/jooq/DropIndexCascadeStep
 org/jooq/DropIndexOnStep
    +on (Lorg/jooq/Table<*>;)Lorg/jooq/DropIndexCascadeStep;
    -on (Lorg/jooq/Table<*>;)Lorg/jooq/DropIndexFinalStep;
 org/jooq/Field
    -getBinding ()Lorg/jooq/Binding<*TT;>;
    -getConverter ()Lorg/jooq/Converter<*TT;>;
    -getDataType ()Lorg/jooq/DataType<TT;>;
    -getDataType (Lorg/jooq/Configuration;)Lorg/jooq/DataType<TT;>;
    -getType ()Ljava/lang/Class<TT;>;
+org/jooq/FilePattern
+org/jooq/FilePattern$Loader
+org/jooq/FilePattern$Sort
 org/jooq/InsertQuery
    +setSelect (Ljava/util/Collection<+Lorg/jooq/Field<*>;>;Lorg/jooq/Select<*>;)V
 org/jooq/JoinType
    +toKeyword
 org/jooq/Key
    +enforced
    -getName
 org/jooq/LoaderCSVStep
    +fields (Lorg/jooq/LoaderFieldMapper;)Lorg/jooq/LoaderCSVOptionsStep<TR;>;
    -fields (Lorg/jooq/LoaderFieldMapper;)Lorg/jooq/LoaderListenerStep<TR;>;
    +fieldsFromSource ()Lorg/jooq/LoaderCSVOptionsStep<TR;>;
 org/jooq/LoaderJSONStep
    +fields (Lorg/jooq/LoaderFieldMapper;)Lorg/jooq/LoaderJSONOptionsStep<TR;>;
    -fields (Lorg/jooq/LoaderFieldMapper;)Lorg/jooq/LoaderListenerStep<TR;>;
    +fieldsFromSource ()Lorg/jooq/LoaderJSONOptionsStep<TR;>;
 org/jooq/LoaderRowsStep
    +fieldsFromSource ()Lorg/jooq/LoaderListenerStep<TR;>;
 org/jooq/LoaderSourceStep
    +loadCSV (Lorg/jooq/Source;)Lorg/jooq/LoaderCSVStep<TR;>;
    +loadJSON (Lorg/jooq/Source;)Lorg/jooq/LoaderJSONStep<TR;>;
    +loadXML (Lorg/jooq/Source;)Lorg/jooq/LoaderXMLStep<TR;>;
 org/jooq/Log
    +log
    +log
    +log
    +log
 org/jooq/Meta
    +apply
    +apply
    +apply
    +apply (Ljava/util/Collection<+Lorg/jooq/Query;>;)Lorg/jooq/Meta;
    +ddl
    +ddl
    +getIndexes ()Ljava/util/List<Lorg/jooq/Index;>;
    +informationSchema
    +migrateTo
    +migrateTo
+org/jooq/Migration
+org/jooq/MigrationConfiguration
+org/jooq/MigrationContext
+org/jooq/MigrationListener
+org/jooq/MigrationListenerProvider
 org/jooq/Name
    +compareTo
    +compareTo
    +empty
 org/jooq/Parameter
    -getBinding ()Lorg/jooq/Binding<*TT;>;
    -getConverter ()Lorg/jooq/Converter<*TT;>;
    -getDataType ()Lorg/jooq/DataType<TT;>;
    -getDataType (Lorg/jooq/Configuration;)Lorg/jooq/DataType<TT;>;
    -getType ()Ljava/lang/Class<TT;>;
+org/jooq/Period
+org/jooq/PeriodSpecification
+org/jooq/PeriodSpecificationBetweenAndStep
+org/jooq/PeriodSpecificationFromToStep
 org/jooq/Queries
    +concat
 org/jooq/SQLDialect
    +predecessors ()Ljava/util/Set<Lorg/jooq/SQLDialect;>;
    +predecessors ([Lorg/jooq/SQLDialect;)Ljava/util/Set<Lorg/jooq/SQLDialect;>;
    +supportedBy (Lorg/jooq/SQLDialect;)Ljava/util/Set<Lorg/jooq/SQLDialect;>;
    +supportedBy ([Lorg/jooq/SQLDialect;)Ljava/util/Set<Lorg/jooq/SQLDialect;>;
    +supportedUntil (Lorg/jooq/SQLDialect;)Ljava/util/Set<Lorg/jooq/SQLDialect;>;
    +supportedUntil ([Lorg/jooq/SQLDialect;)Ljava/util/Set<Lorg/jooq/SQLDialect;>;
 org/jooq/SelectField
    -getBinding ()Lorg/jooq/Binding<*TT;>;
    -getConverter ()Lorg/jooq/Converter<*TT;>;
    -getDataType ()Lorg/jooq/DataType<TT;>;
    -getDataType (Lorg/jooq/Configuration;)Lorg/jooq/DataType<TT;>;
    -getType ()Ljava/lang/Class<TT;>;
 org/jooq/Sequence
    +getCache ()Lorg/jooq/Field<TT;>;
    +getCycle
    -getDataType ()Lorg/jooq/DataType<TT;>;
    +getIncrementBy ()Lorg/jooq/Field<TT;>;
    +getMaxvalue ()Lorg/jooq/Field<TT;>;
    +getMinvalue ()Lorg/jooq/Field<TT;>;
    +getStartWith ()Lorg/jooq/Field<TT;>;
 org/jooq/Source
    +of
    +of
    +of
    +of
    +of
    +of
    +of
    +of
    +readString
    +toString
 org/jooq/Table
    +forPortionOf (Lorg/jooq/PeriodSpecification;)Lorg/jooq/Table<TR;>;
    +for_ (Lorg/jooq/PeriodSpecification;)Lorg/jooq/Table<TR;>;
    +getChecks ()Ljava/util/List<Lorg/jooq/Check<TR;>;>;
    +getOptions
    +getType
+org/jooq/TableOptions
+org/jooq/TableOptions$OnCommit
+org/jooq/TableOptions$TableType
+org/jooq/Typed
+org/jooq/Version
+org/jooq/VersionProvider
+org/jooq/Versions
 org/jooq/WithStep
    +delete <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteUsingStep<TR;>;
    -delete <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteWhereStep<TR;>;
    +selectFrom (Ljava/lang/String;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Ljava/lang/String;[Ljava/lang/Object;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Ljava/lang/String;[Lorg/jooq/QueryPart;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Lorg/jooq/Name;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Lorg/jooq/SQL;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;[Ljava/lang/Object;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;[Lorg/jooq/QueryPart;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Name;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Lorg/jooq/SQL;)Lorg/jooq/SelectWhereStep<TR;>;
+org/jooq/conf/InterpreterNameLookupCaseSensitivity
+org/jooq/conf/InterpreterSearchSchema
+org/jooq/conf/MappedCatalog
 org/jooq/conf/ObjectFactory
    +createInterpreterSearchSchema
    +createMappedCatalog
+org/jooq/conf/ParseNameCase
 org/jooq/conf/RenderMapping
    +getCatalogs ()Ljava/util/List<Lorg/jooq/conf/MappedCatalog;>;
    +getDefaultCatalog
    +setCatalogs (Ljava/util/List<Lorg/jooq/conf/MappedCatalog;>;)V
    +setDefaultCatalog
    +withCatalogs
    +withCatalogs (Ljava/util/Collection<Lorg/jooq/conf/MappedCatalog;>;)Lorg/jooq/conf/RenderMapping;
    +withCatalogs (Ljava/util/List<Lorg/jooq/conf/MappedCatalog;>;)Lorg/jooq/conf/RenderMapping;
    +withDefaultCatalog
+org/jooq/conf/RenderOptionalKeyword
 org/jooq/conf/Settings
    +getInterpreterDialect
    +getInterpreterLocale
    +getInterpreterNameLookupCaseSensitivity
    +getInterpreterSearchPath ()Ljava/util/List<Lorg/jooq/conf/InterpreterSearchSchema;>;
    +getLocale
    +getMigrationListenerEndInvocationOrder
    +getMigrationListenerStartInvocationOrder
    +getParseLocale
    +getParseNameCase
    +getRenderOptionalAsKeywordForFieldAliases
    +getRenderOptionalAsKeywordForTableAliases
    +getRenderOptionalInnerKeyword
    +getRenderOptionalOuterKeyword
    +isApplyWorkaroundFor7962
    +isInterpreterDelayForeignKeyDeclarations
    +isMigrationAllowsUndo
    +isMigrationAutoValidation
    +isMigrationRevertUntracked
    +isParseSetCommands
    +isRenderParenthesisAroundSetOperationQueries
    +isTransformAnsiJoinToTableLists
    +setApplyWorkaroundFor7962
    +setInterpreterDelayForeignKeyDeclarations
    +setInterpreterDialect
    +setInterpreterLocale
    +setInterpreterNameLookupCaseSensitivity
    +setInterpreterSearchPath (Ljava/util/List<Lorg/jooq/conf/InterpreterSearchSchema;>;)V
    +setLocale
    +setMigrationAllowsUndo
    +setMigrationAutoValidation
    +setMigrationListenerEndInvocationOrder
    +setMigrationListenerStartInvocationOrder
    +setMigrationRevertUntracked
    +setParseLocale
    +setParseNameCase
    +setParseSetCommands
    +setRenderOptionalAsKeywordForFieldAliases
    +setRenderOptionalAsKeywordForTableAliases
    +setRenderOptionalInnerKeyword
    +setRenderOptionalOuterKeyword
    +setRenderParenthesisAroundSetOperationQueries
    +setTransformAnsiJoinToTableLists
    +withApplyWorkaroundFor7962
    +withInterpreterDelayForeignKeyDeclarations
    +withInterpreterDialect
    +withInterpreterLocale
    +withInterpreterNameLookupCaseSensitivity
    +withInterpreterSearchPath
    +withInterpreterSearchPath (Ljava/util/Collection<Lorg/jooq/conf/InterpreterSearchSchema;>;)Lorg/jooq/conf/Settings;
    +withInterpreterSearchPath (Ljava/util/List<Lorg/jooq/conf/InterpreterSearchSchema;>;)Lorg/jooq/conf/Settings;
    +withLocale
    +withMigrationAllowsUndo
    +withMigrationAutoValidation
    +withMigrationListenerEndInvocationOrder
    +withMigrationListenerStartInvocationOrder
    +withMigrationRevertUntracked
    +withParseLocale
    +withParseNameCase
    +withParseSetCommands
    +withRenderOptionalAsKeywordForFieldAliases
    +withRenderOptionalAsKeywordForTableAliases
    +withRenderOptionalInnerKeyword
    +withRenderOptionalOuterKeyword
    +withRenderParenthesisAroundSetOperationQueries
    +withTransformAnsiJoinToTableLists
 org/jooq/conf/SettingsTools
    +interpreterLocale
    +locale
    +parseLocale
+org/jooq/exception/DataDefinitionException
+org/jooq/exception/DataMigrationException
+org/jooq/exception/DataMigrationValidationException
 org/jooq/impl/DAOImpl
    +ctx
 org/jooq/impl/DSL
    +alterType
    +alterType
    +createTemporaryTableIfNotExists
    +createTemporaryTableIfNotExists
    +createTemporaryTableIfNotExists (Lorg/jooq/Table<*>;)Lorg/jooq/CreateTableColumnStep;
    +delete <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteUsingStep<TR;>;
    -delete <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteWhereStep<TR;>;
    +deleteFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteUsingStep<TR;>;
    -deleteFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteWhereStep<TR;>;
    +dropTemporaryTableIfExists
    +dropTemporaryTableIfExists
    +dropTemporaryTableIfExists (Lorg/jooq/Table<*>;)Lorg/jooq/DropTableStep;
    +execute
    +period (Lorg/jooq/Name;)Lorg/jooq/Period<Ljava/sql/Timestamp;>;
    +period <T:Ljava/lang/Object;>(Lorg/jooq/Name;Ljava/lang/Class<TT;>;)Lorg/jooq/Period<TT;>;
    +period <T:Ljava/lang/Object;>(Lorg/jooq/Name;Lorg/jooq/DataType<TT;>;)Lorg/jooq/Period<TT;>;
    +primaryKey ([Lorg/jooq/Field<*>;)Lorg/jooq/ConstraintEnforcementStep;
    -primaryKey ([Lorg/jooq/Field<*>;)Lorg/jooq/ConstraintFinalStep;
    +return_
    +return_
    +return_ (Lorg/jooq/Field<*>;)Lorg/jooq/Statement;
    +round <T:Ljava/lang/Number;>(Lorg/jooq/Field<TT;>;Lorg/jooq/Field<Ljava/lang/Integer;>;)Lorg/jooq/Field<TT;>;
    +selectFrom (Ljava/lang/String;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Ljava/lang/String;[Ljava/lang/Object;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Ljava/lang/String;[Lorg/jooq/QueryPart;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Lorg/jooq/Name;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Lorg/jooq/SQL;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;[Ljava/lang/Object;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;[Lorg/jooq/QueryPart;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Name;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Lorg/jooq/SQL;)Lorg/jooq/SelectWhereStep<TR;>;
    +set (Lorg/jooq/Name;Lorg/jooq/Param<*>;)Lorg/jooq/RowCountQuery;
    +statement
    +statement
    +statement
    +statement
    +systemTime ()Lorg/jooq/Period<Ljava/sql/Timestamp;>;
    +systemTime <T:Ljava/lang/Object;>(Ljava/lang/Class<TT;>;)Lorg/jooq/Period<TT;>;
    +systemTime <T:Ljava/lang/Object;>(Lorg/jooq/DataType<TT;>;)Lorg/jooq/Period<TT;>;
    +unique ([Lorg/jooq/Field<*>;)Lorg/jooq/ConstraintEnforcementStep;
    -unique ([Lorg/jooq/Field<*>;)Lorg/jooq/ConstraintFinalStep;
 org/jooq/impl/DefaultConfiguration
    +derive
    +derive
    +derive
    +interpreterConnectionProvider
    +migrationListenerProviders
    +set
    +set
    +set
    +setInterpreterConnectionProvider
    +setSystemConnectionProvider
    +setVersionProvider
    +systemConnectionProvider
    +versionProvider
 org/jooq/impl/DefaultDSLContext
    +alterType
    +alterType
    +createTemporaryTableIfNotExists
    +createTemporaryTableIfNotExists
    +createTemporaryTableIfNotExists (Lorg/jooq/Table<*>;)Lorg/jooq/CreateTableColumnStep;
    +delete <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteUsingStep<TR;>;
    -delete <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteWhereStep<TR;>;
    +deleteFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteUsingStep<TR;>;
    -deleteFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;)Lorg/jooq/DeleteWhereStep<TR;>;
    +dropTemporaryTableIfExists
    +dropTemporaryTableIfExists
    +dropTemporaryTableIfExists (Lorg/jooq/Table<*>;)Lorg/jooq/DropTableStep;
    +meta
    +meta
    +migrateTo
    +selectFrom (Ljava/lang/String;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Ljava/lang/String;[Ljava/lang/Object;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Ljava/lang/String;[Lorg/jooq/QueryPart;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Lorg/jooq/Name;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    +selectFrom (Lorg/jooq/SQL;)Lorg/jooq/SelectWhereStep<Lorg/jooq/Record;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;[Ljava/lang/Object;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Ljava/lang/String;[Lorg/jooq/QueryPart;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Lorg/jooq/Name;)Lorg/jooq/SelectWhereStep<TR;>;
    -selectFrom <R::Lorg/jooq/Record;>(Lorg/jooq/SQL;)Lorg/jooq/SelectWhereStep<TR;>;
    +set (Lorg/jooq/Name;Lorg/jooq/Param<*>;)Lorg/jooq/RowCountQuery;
    +version
 org/jooq/impl/DefaultDataType
    +isInteger
+org/jooq/impl/DefaultMigrationListener
+org/jooq/impl/DefaultMigrationListenerProvider
+org/jooq/impl/DefaultVersionProvider
+org/jooq/impl/IdentityConverter
 org/jooq/impl/InformationSchemaMetaProvider
    +<init>
 org/jooq/impl/Internal
    +createCheck <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;Lorg/jooq/Name;Ljava/lang/String;)Lorg/jooq/Check<TR;>;
    +createCheck <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;Lorg/jooq/Name;Ljava/lang/String;Z)Lorg/jooq/Check<TR;>;
    +createForeignKey <R::Lorg/jooq/Record;U::Lorg/jooq/Record;>(Lorg/jooq/UniqueKey<TU;>;Lorg/jooq/Table<TR;>;Ljava/lang/String;[Lorg/jooq/TableField<TR;*>;Z)Lorg/jooq/ForeignKey<TR;TU;>;
    +createQueue <R::Lorg/jooq/UDTRecord<TR;>;>(Ljava/lang/String;Lorg/jooq/Schema;Lorg/jooq/UDT<TR;>;)Lorg/jooq/util/oracle/Queue<TR;>;
    +createSequence <T:Ljava/lang/Number;>(Ljava/lang/String;Lorg/jooq/Schema;Lorg/jooq/DataType<TT;>;)Lorg/jooq/Sequence<TT;>;
    +createSequence <T:Ljava/lang/Number;>(Ljava/lang/String;Lorg/jooq/Schema;Lorg/jooq/DataType<TT;>;Ljava/lang/Number;Ljava/lang/Number;Ljava/lang/Number;Ljava/lang/Number;ZLjava/lang/Number;)Lorg/jooq/Sequence<TT;>;
    +createUniqueKey <R::Lorg/jooq/Record;>(Lorg/jooq/Table<TR;>;Ljava/lang/String;[Lorg/jooq/TableField<TR;*>;Z)Lorg/jooq/UniqueKey<TR;>;
+org/jooq/impl/LocalDateAsLocalDateTimeBinding
 org/jooq/impl/SequenceImpl
    +getCache ()Lorg/jooq/Field<TT;>;
    +getCycle
    -getDataType ()Lorg/jooq/DataType<TT;>;
    +getIncrementBy ()Lorg/jooq/Field<TT;>;
    +getMaxvalue ()Lorg/jooq/Field<TT;>;
    +getMinvalue ()Lorg/jooq/Field<TT;>;
    +getStartWith ()Lorg/jooq/Field<TT;>;
 org/jooq/impl/TableImpl
    +<init> (Lorg/jooq/Name;Lorg/jooq/Schema;Lorg/jooq/Table<*>;Lorg/jooq/ForeignKey<*TR;>;Lorg/jooq/Table<TR;>;[Lorg/jooq/Field<*>;Lorg/jooq/Comment;Lorg/jooq/TableOptions;)V
    +<init> (Lorg/jooq/Name;Lorg/jooq/Schema;Lorg/jooq/Table<TR;>;[Lorg/jooq/Field<*>;Lorg/jooq/Comment;Lorg/jooq/TableOptions;)V
    +getChecks
 org/jooq/tools/JooqLogger
    +log
    +log
    +log
    +log
 org/jooq/tools/jdbc/Mock
    +of
 org/jooq/tools/jdbc/MockConfiguration
    +derive
    +derive
    +derive
    +interpreterConnectionProvider
    +migrationListenerProviders
    +set
    +set
    +set
    +systemConnectionProvider
    +versionProvider
 org/jooq/tools/jdbc/MockFileDatabase
    +<init>
 org/jooq/tools/jdbc/MockFileDatabaseConfiguration
    +source
 org/jooq/tools/jdbc/MockResult
    +<init>
 org/jooq/tools/reflect/CompileOptions
    +options
    +options (Ljava/util/List<Ljava/lang/String;>;)Lorg/jooq/tools/reflect/CompileOptions;
+org/jooq/util/cockroachdb/CockroachDBDataType
 org/jooq/util/jaxb/tools/MiniJAXB
    +unmarshal <T::Lorg/jooq/util/jaxb/tools/XMLAppendable;>(Ljava/io/Reader;Ljava/lang/Class<TT;>;)TT;
+org/jooq/util/xml/jaxb/CheckConstraint
 org/jooq/util/xml/jaxb/InformationSchema
    +getCheckConstraints ()Ljava/util/List<Lorg/jooq/util/xml/jaxb/CheckConstraint;>;
    +getViews ()Ljava/util/List<Lorg/jooq/util/xml/jaxb/View;>;
    +setCheckConstraints (Ljava/util/List<Lorg/jooq/util/xml/jaxb/CheckConstraint;>;)V
    +setViews (Ljava/util/List<Lorg/jooq/util/xml/jaxb/View;>;)V
    +withCheckConstraints
    +withCheckConstraints (Ljava/util/Collection<Lorg/jooq/util/xml/jaxb/CheckConstraint;>;)Lorg/jooq/util/xml/jaxb/InformationSchema;
    +withCheckConstraints (Ljava/util/List<Lorg/jooq/util/xml/jaxb/CheckConstraint;>;)Lorg/jooq/util/xml/jaxb/InformationSchema;
    +withViews
    +withViews (Ljava/util/Collection<Lorg/jooq/util/xml/jaxb/View;>;)Lorg/jooq/util/xml/jaxb/InformationSchema;
    +withViews (Ljava/util/List<Lorg/jooq/util/xml/jaxb/View;>;)Lorg/jooq/util/xml/jaxb/InformationSchema;
 org/jooq/util/xml/jaxb/ObjectFactory
    +createCheckConstraint
    +createView
 org/jooq/util/xml/jaxb/Sequence
    +getCache
    +getIncrement
    +getMaximumValue
    +getMinimumValue
    +getStartValue
    +isCycleOption
    +setCache
    +setCycleOption
    +setIncrement
    +setMaximumValue
    +setMinimumValue
    +setStartValue
    +withCache
    +withCycleOption
    +withIncrement
    +withMaximumValue
    +withMinimumValue
    +withStartValue
 org/jooq/util/xml/jaxb/Table
    +getTableType
    +setTableType
    +withTableType
 org/jooq/util/xml/jaxb/TableConstraint
    +isEnforced
    +setEnforced
    +withEnforced
+org/jooq/util/xml/jaxb/TableType
+org/jooq/util/xml/jaxb/View

And we're in full control of the output and algorithm. For example, I would want to ignore the binary incompatible changes, if they're source compatible (a method returns a new subtype of the previously returned type)

lukaseder

comment created time in 2 days

issue commentjOOQ/jOOQ

Publish an API diff in the manual using japicmp

I will look into this. Rather than reverse engineering some third party library, I think I'll just roll my own little script based on ASM

lukaseder

comment created time in 2 days

issue commentjOOQ/jOOQ

Add a way to load POJOs into Records without setting all the changed flags to true

For context: A non representative Twitter poll shows that the existing behaviour of Record types is desireable: https://twitter.com/lukaseder/status/1232327845969629185

Setting a value to something means the intent is for that action to have a side effect in the generated query. Good reasons are:

  1. that's what jOOQ is already doing
  2. in SQL, NULL and DEFAULT are not the same
  3. in the presence of plan caches, you don't want too many different SQL strings and hard parses (at least you want control)

This issue here is about loading POJOs / DTOs into records with Record::from and similar methods. Record behaviour itself will not be modified.

lukaseder

comment created time in 2 days

issue openedjOOQ/jOOQ

Add support for client side GENERATED [ ALWAYS | BY DEFAULT ] AS

Many dialects have native support for server side computed columns using syntaxes such as GENERATED [ ALWAYS | BY DEFAULT ] AS. These are useful for:

  • Replacing triggers to produce identity values / sequence generated values or UUID primary key values
  • Calculate some expression that can be used in an index. It's generally a cleaner approach than function based indexes, as the use site does not have to remember and repeat the expression in every query in order for the computed column's index to apply.

If a dialect doesn't support these features, or in some cases where the feature is not good enough for various reasons (e.g. Oracle doesn't support materialised computed columns, which would be useful if the computation is CPU intensive), it would be nice to have this feature in jOOQ, client side.

Users can already implement it using RecordListener, but this feature would affect also any explicitly constructed INSERT, UPDATE or MERGE statement, including parsed ones, if meta data lookup is applied.

The following changes are needed:

  • [ ] Additional information on the DataType meta model, where we already know the server side DEFAULT expression.
  • [ ] Code generation support to read server side GENERATED expressions into this new feature
  • [ ] Code generation support to produce synthetic GENERATED expressions
  • [ ] Settings to enable / disable the feature
  • [ ] Implementation logic
  • [ ] Synthetic CREATE TABLE and ALTER TABLE DDL support for the interpreter

With a synthetic table definition like this:

CREATE TABLE t (
  i INT,
  j INT CLIENT GENERATED ALWAYS AS 1,
  k INT CLIENT GENERATED BY DEFAULT AS 2
);

The following statements...

INSERT INTO t (i, j) VALUES (0, 0);
INSERT INTO t (i, j, k) VALUES (0, 0, 0);
INSERT INTO t (i, j, k) SELECT 0, 0, 0;
UPDATE t SET i = 0, j = 0, k = 0;

... would be transformed to these ones

INSERT INTO t (i, j, k) VALUES (0, 1, 2);
INSERT INTO t (i, j, k) VALUES (0, 1, 0);
INSERT INTO t (i, j, k) SELECT c1, 1, c3 FROM (SELECT 0, 0, 0) t(c1, c2, c3);
UPDATE t SET i = 0, j = 1, k = 0;

There will obviously be edge cases which are not properly handled in the above examples yet.

created time in 2 days

issue commentjOOQ/jOOQ

Add a way to load POJOs into Records without setting all the changed flags to true

The difficult thing with changing the semantics globally is that while some operations have an available Scope, and thus Settings, others do not. For example, a statically created query could receive an non-attached record like this:

// The record is not attached, so it doesn't have a Settings, meaning that the from() call
// will set the third column to "changed", despite it being null before and after the from() call
TRecord record = new TRecord();
record.from(new TPojo(1, 2, null));

// This call also cannot access any Settings to override the default behaviour of changed(),
// so the third column will have a "null" value being inserted explicitly
Insert insert =
DSL.insertInto(T)
   .set(record)

In order to apply Settings reasonably, we'd have to make all of the above operations lazy, which is a can of worms I don't want to open for this minor feature.

Besides, even if the operations are lazy, the behaviour of toString() on Scope-free objects would resemble the current behaviour, whereas that of DSLContext.render() would be different. There are probably many other, similarly confusing differences in this already quite confusing area.

lukaseder

comment created time in 2 days

issue commentjOOQ/jOOQ

Add a way to load POJOs into Records without setting all the changed flags to true

A somewhat similar feature is DSLContext::fetchByExample, which delegates to DSL.condition(Record). An "example" record produces a condition from all the non-null values. This partially matches what the expectation is here, where only non-null POJO values should be copied into new records. It is not exactly the same, because if the record is not new, there may be pre-existing values in the record, in case of which setting a value to null would constitute a change of value.

lukaseder

comment created time in 2 days

issue commentjOOQ/jOOQ

Add a way to load POJOs into Records without setting all the changed flags to true

The change of semantics governs how the following operations work:

  • [ ] UpdatableRecord.store(), update(), insert() only copy changed values to the respective INSERT or UPDATE query, leaving the unchanged values untouched.
  • [ ] Copying record values to other records is done only for source values that are changed
  • [ ] When calling set(Record) on an Insert, Update, or Merge statement, only changed values are transferred

At least the following operations will be affected by or may be modified for a semantic shift from changed meaning "touched" to "having a modified value":

  • [ ] After UpdatableRecord.delete(), the entire record is changed(true), such that a subsequent store() call will insert the entire record again
  • [ ] Changing the primary key means that the entire record is changed(true), because we don't update primary key values by default, we only insert such modifications.
  • [ ] When records are created and values are set by jOOQ's internals (e.g. results from INSERT .. RETURNING calls), the records get a changed(false) call meaning the entire record is "untouched"

There are special cases which lie in between the two semantics

  • [ ] When null values are loaded from POJOs into records, and there's a known NOT NULL constraint on the record. In that case, we already look set the null value as not changed (such that DEFAULT values can apply). See #2700, #3582
  • [ ] When DAOs load POJOs into records, the assumption is that the primary key value is never changed when loading the POJO for an UPDATE statement

Operations that will not be affected by the change of semantics:

  • [ ] Setting a changed flag to false on a column overwrites the original() value for that column and sets it to the current value. See #1995
lukaseder

comment created time in 2 days

create barnchlukaseder/jooq-basic-sample

branch : master

created branch time in 2 days

created repositorylukaseder/jooq-basic-sample

A basic example of using jOOQ with CockroachDB

created time in 2 days

issue commentjOOQ/jOOQ

Liquibase imports should use ClassLoaderResourceAccessor

That would be confusing to non-maven users. As mentioned before, it's not the only place in the manual where we use paths, relative or not, so I'm not sure we should have this ${basedir} variable in our XMLs

paulius-p

comment created time in 2 days

issue closedjOOQ/jOOQ

Liquibase imports should use ClassLoaderResourceAccessor

Use case:

I've been looking forward to Liquibase support in jOOQ! That's a great addition!

Just noticed that by default it uses FileSystemResourceAccessor, which needs you to define all the migrations in absolute paths (or use relativeToChangelogFile flag everywhere, but even then in some cases it won't suffice). And that's not desirable, as usually you don't want to have absolute paths in you migrations file.

The default behaviour in Liquibase is to use ClassLoaderResourceAccessor:

https://github.com/liquibase/liquibase/blob/01b3899923e0dbd3d52e14f0bf145732c3c18a68/liquibase-maven-plugin/src/main/java/org/liquibase/maven/plugins/AbstractLiquibaseMojo.java#L433 https://github.com/liquibase/liquibase/blob/01b3899923e0dbd3d52e14f0bf145732c3c18a68/liquibase-core/src/main/java/liquibase/Scope.java#L99

And in liquibase-maven-plugin plugin (which is what I'm using now for generating jOOQ files) it uses CompositeResourceAccessor:

https://github.com/liquibase/liquibase/blob/01b3899923e0dbd3d52e14f0bf145732c3c18a68/liquibase-maven-plugin/src/main/java/org/liquibase/maven/plugins/AbstractLiquibaseChangeLogMojo.java#L91-L103

Improving this would definitely ease the effort to adopt this new Liquibase feature.

Test case:

Configuration (in this case it doesn't even find the changelog if ${project.basedir}/ is not prefixed):

  <database>
    <name>org.jooq.meta.extensions.liquibase.LiquibaseDatabase</name>
    <properties>
      <property>
        <key>scripts</key>
        <value>${project.basedir}/src/main/resources/db/changelog/db.changelog-master.yaml</value>
      </property>
      <property>
        <key>includeLiquibaseTables</key>
        <value>false</value>
      </property>
      <property>
        <key>database.contexts</key>
        <value>default</value>
      </property>
    </properties>
    ...
  </database>

Migrations file:

databaseChangeLog:
  - context: default
  - include:
      - file: db/changelog/v1-0-0/db.changelog.yaml
  - include:
      - file: db/changelog/v1-1-0/change-some-columns.yaml

Versions:

  • jOOQ: 3.13.1
  • Java: 11
  • Database (include vendor): H2
  • OS: Linux
  • JDBC Driver (include name if inofficial driver):

closed time in 3 days

paulius-p

issue commentjOOQ/jOOQ

Liquibase imports should use ClassLoaderResourceAccessor

Implemented in jOOQ 3.14.0. Backport scheduled for 3.13.2 (#9878)

paulius-p

comment created time in 3 days

push eventjOOQ/jOOQ

Lukas Eder

commit sha 41a64fca23d4409410c34c41907ebe3e6bf93c2e

[jOOQ/jOOQ#9866] Liquibase imports should use ClassLoaderResourceAccessor

view details

push time in 3 days

push eventjOOQ/jOOQ

Lukas Eder

commit sha 1c9f7f5a66b7e762722ce253738a17bd848abb60

[jOOQ/jOOQ#9866] Liquibase imports should use ClassLoaderResourceAccessor

view details

push time in 3 days

issue commentjOOQ/jOOQ

Liquibase imports should use ClassLoaderResourceAccessor

Hmm, I'm getting the expected results using this:

new CompositeResourceAccessor(
    new FileSystemResourceAccessor(),
    new ClassLoaderResourceAccessor(),
    new ClassLoaderResourceAccessor(Thread.currentThread().getContextClassLoader())
),

The first ClassLoaderResourceAccessor is used for standalone code generator usage (via GenerationTool::main), and the second one uses our jOOQ Maven Plugin classloader, which is placed in the current thread's context class loader.

I'll commit soon. Would be happy to get early feedback, if you have time.

paulius-p

comment created time in 3 days

issue commentjOOQ/jOOQ

Liquibase imports should use ClassLoaderResourceAccessor

I see, thanks for clarifying.

paulius-p

comment created time in 3 days

issue commentjOOQ/jOOQ

Liquibase imports should use ClassLoaderResourceAccessor

Thank you very much for your suggestion. Uniform path descriptors do seem to be an unsolved problem in the Java ecosystem...

There's probably room for improvement here, but I personally don't find the ${basedir} prefix such a bad approach.

Notice the LiquibaseDatabase is in the jOOQ-meta-extensions module, which does not know anything about it possibly being used in Maven. Since Maven already supports resolving relative paths to absolute ones very cleanly using these properties, I think this is the cleanest approach.

But we might consider an improvement through a more generic approach, which affects all of our utilities, not just the LiquibaseDatabase

paulius-p

comment created time in 3 days

CommitCommentEvent

push eventjOOQ/jOOQ

Lukas Eder

commit sha 5de3cfdf1e1f6cbe008ccaf9ab4b2c1aa6757653

[jOOQ/jOOQ#9873] LiquibaseDatabase should use actual changeLog database table names

view details

push time in 3 days

issue closedjOOQ/jOOQ

LiquibaseDatabase should use actual changeLog database table names

Expected behavior and actual behavior:

Currently when excluding liquibase changeLog tables, static table name values are used, but those might be overridden by the configuration setters.

Versions:

  • jOOQ: 3.13.1
  • Java: 11
  • Database (include vendor):
  • OS:
  • JDBC Driver (include name if inofficial driver):

closed time in 3 days

Fadelis

issue commentjOOQ/jOOQ

LiquibaseDatabase should use actual changeLog database table names

Integrated in jOOQ 3.14.0. Backport scheduled for 3.13.2 (#9877).

Thanks again!

Fadelis

comment created time in 3 days

pull request commentjOOQ/jOOQ

[#9873] LiquibaseDatabase should use actual changeLog table names

Thanks a lot for the suggested improvement. Agreed

Fadelis

comment created time in 3 days

push eventjOOQ/jOOQ

Fadelis

commit sha fbdc70e0a0a9a22365f06bbe303c44be9e8c3375

[#9873] LiquibaseDatabase use correct changeLog table names as they might be overridden

view details

Lukas Eder

commit sha db1d75b28875324a15635b91642f52cdb4f6c538

Merge pull request #9875 from Fadelis/feature/liquibase-changelog-table-names [#9873] LiquibaseDatabase should use actual changeLog table names

view details

push time in 3 days

PR merged jOOQ/jOOQ

Reviewers
[#9873] LiquibaseDatabase should use actual changeLog table names C: Code Generation C: Integration: Liquibase E: All Editions P: Medium T: Defect
+6 -1

0 comment

1 changed file

Fadelis

pr closed time in 3 days

issue commentjOOQ/jOOQ

LiquibaseDatabase should use actual changeLog database table names

Thanks a lot for your suggestion. Agreed, that currently doesn't work correctly for non-out-of-the-box configurations.

Fadelis

comment created time in 3 days

CommitCommentEvent

push eventjOOQ/jOOQ

Lukas Eder

commit sha 919910ffff63801e1e76d815e48c1c454a0aa615

[jOOQ/jOOQ#9872] LiquibaseDatabase should use configured changeLogParameters.contexts when updating

view details

push time in 3 days

issue closedjOOQ/jOOQ

LiquibaseDatabase should use configured changeLogParameters.contexts when updating

Use case:

Currently liquibase contexts parameter is not applied correctly as it is not a database property and needs to be passed to the database.update(String) method to work correctly.

Possible solution you'd like to see:

Include explicit contexts property and pass it to the update method

Versions:

  • jOOQ: 3.13.1
  • Java: 11
  • Database (include vendor):
  • OS:
  • JDBC Driver (include name if inofficial driver):

closed time in 3 days

Fadelis

issue commentjOOQ/jOOQ

LiquibaseDatabase should use configured changeLogParameters.contexts when updating

Implemented in jOOQ 3.14.0. Backport scheduled for 3.13.2 (#9876).

Thanks again!

Fadelis

comment created time in 3 days

push eventjOOQ/jOOQ

Lukas Eder

commit sha b393fdd738250b2823675610637f5de6d6c266a2

[jOOQ/jOOQ#9872] Minor improvement

view details

push time in 3 days

push eventjOOQ/jOOQ

Lukas Eder

commit sha 2d0409df23ecd17608dea4d3fc60188294446094

[jOOQ/jOOQ#9872] LiquibaseDatabase should use configured changeLogParameters.contexts when updating

view details

Lukas Eder

commit sha 89f36f2f3bffdaec34ab5e36edadec4423cfd03e

Cosmetic changes

view details

push time in 3 days

push eventjOOQ/jOOQ

Fadelis

commit sha fdb4bbd79d93caaafdb6281699473f53034df60a

[#9872] LiquibaseDatabase should use provided contexts on update

view details

Lukas Eder

commit sha eaeb60ec73a55112059cfc7e21cb252a4aff3169

Merge pull request #9874 from Fadelis/feature/liquibase-contexts [#9872] LiquibaseDatabase should use provided contexts on update

view details

push time in 3 days

PR merged jOOQ/jOOQ

Reviewers
[#9872] LiquibaseDatabase should use provided contexts on update C: Code Generation C: Integration: Liquibase E: All Editions P: Medium T: Enhancement
+3 -2

1 comment

1 changed file

Fadelis

pr closed time in 3 days

pull request commentjOOQ/jOOQ

[#9872] LiquibaseDatabase should use provided contexts on update

Thanks a lot for your suggestion. I'll merge and fix according to my comments. I think we can safely backport this to 3.13.2, for immediate availability as well.

Fadelis

comment created time in 3 days

Pull request review commentjOOQ/jOOQ

[#9872] LiquibaseDatabase should use provided contexts on update

     @Override     protected void export() throws Exception {         String scripts = getProperties().getProperty("scripts");-        includeLiquibaseTables = Boolean.valueOf(getProperties().getProperty("includeLiquibaseTables", "false"));+        String liquibaseContexts = getProperties().getProperty("contexts", "");

Inside of Liquibase, the Contexts object gets passed along to changeLogParameters. I'd say, we call it changeLogParameters.contexts.

Fadelis

comment created time in 3 days

CommitCommentEvent

issue commentjOOQ/jOOQ

LiquibaseDatabase should use provided contexts when updating

Thanks a lot for your suggestion. I agree that this contexts string would be a useful property to pass along.

I will comment on your commit

Fadelis

comment created time in 3 days

issue commentjOOQ/jOOQ

LiquibaseDatabase should allow for passing parameters to the Liquibase

Thanks a lot!

For the reference, new issues here: https://github.com/jOOQ/jOOQ/issues/9872, https://github.com/jOOQ/jOOQ/issues/9873

lukaseder

comment created time in 3 days

issue commentjOOQ/jOOQ

LiquibaseDatabase should allow for passing parameters to the Liquibase

Thanks for your suggestions, @Fadelis. We can certainly improve things in this area. I'd prefer doing this under new issues, so we can properly announce the changes in the release notes. From your commits, I can see that you're already improving more than just the contexts parameters.

Would you mind creating individual issues with a short explanation about what this is for?

lukaseder

comment created time in 3 days

issue closedjOOQ/jOOQ

OracleDatabase produces wrong query when tableValuedFunctions is active

There is a regression in how the code generator produces the query for fetching tables in Oracle, when the <tableValuedFunctions/> flag is activated. Historically, this flag is deactivated in Oracle, so most users will not see the problem.

The error is this

Exception while executing meta query: ORA-01789: query block has incorrect number of result columns

The erroneous query is this:

select 
  alias_38992254.OWNER, 
  alias_38992254.TABLE_NAME, 
  alias_38992254.COMMENTS, 
  alias_38992254.OBJECT_ID, 
  alias_38992254.OVERLOAD, 
  alias_38992254.table_type, 
  alias_38992254.TEXT
from (
  select 
    SYS.ALL_TAB_COMMENTS.OWNER, 
    SYS.ALL_TAB_COMMENTS.TABLE_NAME, 
    SYS.ALL_TAB_COMMENTS.COMMENTS, 
    0 OBJECT_ID, 
    '' OVERLOAD, 
    case
      when SYS.ALL_TAB_COMMENTS.TABLE_TYPE = 'VIEW' then 'VIEW'
      when SYS.ALL_TABLES.TEMPORARY = 'Y' then 'TEMPORARY'
      else 'TABLE'
    end table_type, 
    SYS.ALL_VIEWS.TEXT
  from SYS.ALL_TAB_COMMENTS
    left outer join SYS.ALL_TABLES
      on (
        SYS.ALL_TAB_COMMENTS.OWNER = SYS.ALL_TABLES.OWNER
        and SYS.ALL_TAB_COMMENTS.TABLE_NAME = SYS.ALL_TABLES.TABLE_NAME
      )
    left outer join SYS.ALL_VIEWS
      on (
        SYS.ALL_TAB_COMMENTS.OWNER = SYS.ALL_VIEWS.OWNER
        and SYS.ALL_TAB_COMMENTS.TABLE_NAME = SYS.ALL_VIEWS.VIEW_NAME
      )
  where SYS.ALL_TAB_COMMENTS.OWNER in ('TEST')
  union all 
  select 
    SYS.ALL_MVIEWS.OWNER, 
    SYS.ALL_MVIEWS.MVIEW_NAME, 
    SYS.ALL_MVIEW_COMMENTS.COMMENTS, 
    0 OBJECT_ID, 
    '' OVERLOAD, 
    'MATERIALIZED_VIEW' table_type, 
    null TEXT
  from SYS.ALL_MVIEWS
    left outer join SYS.ALL_MVIEW_COMMENTS
      on (
        SYS.ALL_MVIEWS.OWNER = SYS.ALL_MVIEW_COMMENTS.OWNER
        and SYS.ALL_MVIEWS.MVIEW_NAME = SYS.ALL_MVIEW_COMMENTS.MVIEW_NAME
      )
  where SYS.ALL_MVIEWS.OWNER in ('TEST')
) alias_38992254
union all 
select 
  SYS.ALL_OBJECTS.OWNER, 
  SYS.ALL_OBJECTS.OBJECT_NAME, 
  '', 
  SYS.ALL_OBJECTS.OBJECT_ID, 
  SYS.ALL_ARGUMENTS.OVERLOAD, 
  'FUNCTION' table_type
from SYS.ALL_OBJECTS
  join SYS.ALL_ARGUMENTS
    on (
      SYS.ALL_OBJECTS.OWNER = SYS.ALL_ARGUMENTS.OWNER
      and SYS.ALL_OBJECTS.OBJECT_NAME = SYS.ALL_ARGUMENTS.OBJECT_NAME
    )
where (
  SYS.ALL_OBJECTS.OWNER in ('TEST')
  and SYS.ALL_OBJECTS.OBJECT_TYPE in ('FUNCTION')
  and SYS.ALL_ARGUMENTS.PACKAGE_NAME is null
  and SYS.ALL_ARGUMENTS.POSITION = 0
  and SYS.ALL_ARGUMENTS.DATA_LEVEL = 0
  and SYS.ALL_ARGUMENTS.IN_OUT = 'OUT'
  and SYS.ALL_ARGUMENTS.DATA_TYPE in (
    'VARRAY', 'TABLE'
  )
)
order by 
  1, 
  2

The problem went undetected in the compiler because the unions are nested, and the outer most union uses Record, instead of Record7<String, String, String, BigDecimal, String, String, String>

closed time in 3 days

lukaseder

issue commentjOOQ/jOOQ

OracleDatabase produces wrong query when tableValuedFunctions is active

This is a 3.13 regression introduced with #9805. 3.12 is not affected.

Fixed in 3.14.0. Backport scheduled for 3.13.2 (#9871)

lukaseder

comment created time in 3 days

issue openedjOOQ/jOOQ

OracleDatabase produces wrong query when tableValuedFunctions is active

There is a regression in how the code generator produces the query for fetching tables in Oracle, when the <tableValuedFunctions/> flag is activated. Historically, this flag is deactivated in Oracle, so most users will not see the problem.

The error is this

Exception while executing meta query: ORA-01789: query block has incorrect number of result columns

The erroneous query is this:

select 
  alias_38992254.OWNER, 
  alias_38992254.TABLE_NAME, 
  alias_38992254.COMMENTS, 
  alias_38992254.OBJECT_ID, 
  alias_38992254.OVERLOAD, 
  alias_38992254.table_type, 
  alias_38992254.TEXT
from (
  select 
    SYS.ALL_TAB_COMMENTS.OWNER, 
    SYS.ALL_TAB_COMMENTS.TABLE_NAME, 
    SYS.ALL_TAB_COMMENTS.COMMENTS, 
    0 OBJECT_ID, 
    '' OVERLOAD, 
    case
      when SYS.ALL_TAB_COMMENTS.TABLE_TYPE = 'VIEW' then 'VIEW'
      when SYS.ALL_TABLES.TEMPORARY = 'Y' then 'TEMPORARY'
      else 'TABLE'
    end table_type, 
    SYS.ALL_VIEWS.TEXT
  from SYS.ALL_TAB_COMMENTS
    left outer join SYS.ALL_TABLES
      on (
        SYS.ALL_TAB_COMMENTS.OWNER = SYS.ALL_TABLES.OWNER
        and SYS.ALL_TAB_COMMENTS.TABLE_NAME = SYS.ALL_TABLES.TABLE_NAME
      )
    left outer join SYS.ALL_VIEWS
      on (
        SYS.ALL_TAB_COMMENTS.OWNER = SYS.ALL_VIEWS.OWNER
        and SYS.ALL_TAB_COMMENTS.TABLE_NAME = SYS.ALL_VIEWS.VIEW_NAME
      )
  where SYS.ALL_TAB_COMMENTS.OWNER in ('TEST')
  union all 
  select 
    SYS.ALL_MVIEWS.OWNER, 
    SYS.ALL_MVIEWS.MVIEW_NAME, 
    SYS.ALL_MVIEW_COMMENTS.COMMENTS, 
    0 OBJECT_ID, 
    '' OVERLOAD, 
    'MATERIALIZED_VIEW' table_type, 
    null TEXT
  from SYS.ALL_MVIEWS
    left outer join SYS.ALL_MVIEW_COMMENTS
      on (
        SYS.ALL_MVIEWS.OWNER = SYS.ALL_MVIEW_COMMENTS.OWNER
        and SYS.ALL_MVIEWS.MVIEW_NAME = SYS.ALL_MVIEW_COMMENTS.MVIEW_NAME
      )
  where SYS.ALL_MVIEWS.OWNER in ('TEST')
) alias_38992254
union all 
select 
  SYS.ALL_OBJECTS.OWNER, 
  SYS.ALL_OBJECTS.OBJECT_NAME, 
  '', 
  SYS.ALL_OBJECTS.OBJECT_ID, 
  SYS.ALL_ARGUMENTS.OVERLOAD, 
  'FUNCTION' table_type
from SYS.ALL_OBJECTS
  join SYS.ALL_ARGUMENTS
    on (
      SYS.ALL_OBJECTS.OWNER = SYS.ALL_ARGUMENTS.OWNER
      and SYS.ALL_OBJECTS.OBJECT_NAME = SYS.ALL_ARGUMENTS.OBJECT_NAME
    )
where (
  SYS.ALL_OBJECTS.OWNER in ('TEST')
  and SYS.ALL_OBJECTS.OBJECT_TYPE in ('FUNCTION')
  and SYS.ALL_ARGUMENTS.PACKAGE_NAME is null
  and SYS.ALL_ARGUMENTS.POSITION = 0
  and SYS.ALL_ARGUMENTS.DATA_LEVEL = 0
  and SYS.ALL_ARGUMENTS.IN_OUT = 'OUT'
  and SYS.ALL_ARGUMENTS.DATA_TYPE in (
    'VARRAY', 'TABLE'
  )
)
order by 
  1, 
  2

The problem went undetected in the compiler because the unions are nested, and the outer most union uses Record, instead of Record7<String, String, String, BigDecimal, String, String, String>

created time in 3 days

issue commentjOOQ/jOOQ

dropIndexIfExists doesn't add schema to the name even when specified

Other features (such as ALTER INDEX .. RENAME, #5724) have worked around this by explicitly qualifying an index at the use-site. I'd like to fix this more thoroughly.

brsanthu

comment created time in 3 days

issue commentjOOQ/jOOQ

dropIndexIfExists doesn't add schema to the name even when specified

Marking this as an incompatible change (of behaviour), as the behaviour of org.jooq.Index::getQualifiedName and other methods might change incompatibly.

brsanthu

comment created time in 3 days

issue commentjOOQ/jOOQ

dropIndexIfExists doesn't add schema to the name even when specified

Fixing this seems to be more complex than it first seems. The current implementation relies on IndexImpl.NO_SUPPORT_INDEX_QUALIFICATION to indicate whether it is possible to generally qualify an index with schema and/or table names (the table qualification is another dimension of complication, distinguishing dialects that have per-table index namespaces, vs. the ones that have per-schema index namespaces).

It seems that this fix is a more complicated one, making it an unlikely candidate for a backport. We need to fix this nonetheless, of course.

brsanthu

comment created time in 3 days

issue commentjOOQ/jOOQ

dropIndexIfExists doesn't add schema to the name even when specified

Interesting, thank you very much for your report. The current implementation was made based on the assumption that index qualification isn't possible, because it isn't in CREATE INDEX statements. The following is invalid in PostgreSQL:

create schema s;
create table s.t(i int);
create index s.i on s.t(i); -- cannot qualify "i" here

But apparently, dropping is a different story.

brsanthu

comment created time in 3 days

issue commentjOOQ/jOOQ

Code on SQL building path should not throw exceptions

I found this call site, but didn't find any integration test using this.

Look at AbstractRoutine.RoutineField usage

knutwannheden

comment created time in 3 days

issue commentjOOQ/jOOQ

Code on SQL building path should not throw exceptions

I found this call site, but didn't find any integration test using this. Possibly that is just missing.

testPostgresUnnestArrayOfRecord

knutwannheden

comment created time in 3 days

issue commentjOOQ/jOOQ

Code on SQL building path should not throw exceptions

Do we have an example of using FunctionTable?

DSL::unnest0

knutwannheden

comment created time in 3 days

issue commentjOOQ/jOOQ

Code on SQL building path should not throw exceptions

Quite a few places! I'm marking this as an incompatible change as users might have grown used to catching such exceptions, which will no longer occur - at least not in the same way

knutwannheden

comment created time in 3 days

issue closedjOOQ/jOOQ

Emulate Oracle's LISTAGG() in SQL Server using STUFF

this is an example:

SELECT Column1,
stuff((
    SELECT ', ' + Column2
    FROM tableName as t1
    where t1.Column1 = t2.Column1
    FOR XML PATH('')
    ), 1, 2, '')
FROM tableName as t2
GROUP BY Column1

closed time in 3 days

lukaseder

issue commentjOOQ/jOOQ

Emulate Oracle's LISTAGG() in SQL Server using STUFF

I think that a formal emulation of this functionality will quickly turn out to be too complicated, as all sorts of joins, derived tables, etc. need to be duplicated in the emulation's correlated subquery.

lukaseder

comment created time in 3 days

push eventjOOQ/jOOQ

Lukas Eder

commit sha b8ba82b880e01d96fff74040e5fdd4dab98fd021

Release 3.13.1

view details

Lukas Eder

commit sha a910ddf3a72af1b4e4e9e7cb913475663607ba3c

Merge branch 'version-3.13.0-branch' of https://github.com/jOOQ/jOOQ into version-3.13.0-branch

view details

Lukas Eder

commit sha 05d33286ac5e179631a6d2709daadfd15a59b4d5

Release 3.13.2-SNAPSHOT

view details

Lukas Eder

commit sha 10ea26ce41608311520998595e009334bbcde1d1

[jOOQ/jOOQ#9833] Add missing @Support annotation to DSLContext#fetch*() methods

view details

push time in 3 days

issue commentjOOQ/jOOQ

Add missing @Support annotation to DSLContext#fetch*() methods

Fixed in 3.14.0. Backport scheduled for 3.13.2 (#9867)

knutwannheden

comment created time in 3 days

issue closedjOOQ/jOOQ

Add missing @Support annotation to DSLContext#fetch*() methods

Many of the DSLContext#fetch*() methods currently don't have an @Support annotation.

closed time in 3 days

knutwannheden

push eventjOOQ/jOOQ

Lukas Eder

commit sha c15f770d427a0bfa26ca3befb8be77ae7ec7424c

[jOOQ/jOOQ#9833] Add missing @Support annotation to DSLContext#fetch*() methods

view details

push time in 3 days

more