columns in different order than in the unique key definition
- Added new runtime meta API
- Added interpreter and org.jooq.Meta support
- Added code generation support
- Generic type variable returning methods don't need to be annotated
- Annotated some SPIs
- Annotated Result, Cursor, and many other types
- Enhance AnnotationTest to validate jOOQ API without Support annotation
- Add InstrumentationTests to assert correctness of jOOQ-test-agent
- Don't expect annotations on XJC generated code
- Exclude default methods for now (Byte Buddy bug?)
- [jOOQ/jOOQ#10294] Remove methods from RenderContext and BindContext
- Added org.jooq.Domain
- Add DSL API to construct domain references
- Add code generator support for domains
- Add DDL support for domains (CREATE, ALTER, DROP)
- Add parser support
- Add dialect support (H2, PostgreSQL, SQL Server)
Add commits after each table to avoid unnecessary UNDO tablespace growth due to one big transaction
DISABLE and ENABLE constraints rather than DROP and CREATE so taht constraint definition remains in schema.sql alone
Signed-off-by: Gerald Venzl <gerald.venzl@gmail.com>
When using the Sakila DB with the Docker image postgres:12.1 the
initialisation fails with:
ERROR: language "plpgsql" already exists
With PostgreSQL 8.4 (see [1]) and earlier it was only possible to
execute:
CREATE [ PROCEDURAL ] LANGUAGE name
Starting with PostgreSQL 9.0 (see [2]) it is possible to execute:
CREATE [ OR REPLACE ] [ PROCEDURAL ] LANGUAGE name
This commit makes the SQL script incompatible with PostgreSQL 8.4
and earlier.
[1] https://www.postgresql.org/docs/8.4/sql-createlanguage.html
[2] https://www.postgresql.org/docs/9.0/sql-createlanguage.html
In the generated `CatalogImpl` subclasses the static fields representing
the schemas of the catalog typically don't need a fully qualified class
reference in the initializer expression, since the Java type is imported
already.
Additionally the Javadoc comment of the field representing the default
schema (if any) will now also include the schema's name (before it was
missing).
Fixes the Javadoc comment of the default catalog and schema singletons
generated into the `CatalogImpl` and `SchemaImpl` subclasses. For the
default catalog and schema the name was always empty.
In the generated `SchemaImpl` subclasses the static fields representing
the tables of the schema typically don't need a fully qualified class
reference in the initializer expression, since the Java type is imported
already.
The genereated `SchemaImpl` and `CatalogImpl` subclasses will only
declare methods like `getSchemas0()` and `getTables0()` when necessary.
I.e. when the number of returned definitions exceeds 500.
Now all `pom.xml` files explicitly state the version in the `<version>`
element. E.g. `<version>3.13.0-SNAPSHOT</version>`. Dependencies to
other jOOQ modules are always declared using
`<version>${project.version}</version>`.
