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>`.
The jOOQ 3.12 Open Source Edition will continue to support Java 8. The only things we gain from the JDK 11 dependency is:
- Updated logic for reflection when mapping into proxied default methods (that stuff has changed completely in JDK 9). This is a regression, which we can live with. The workaround is to write a custom
- Explicit dependency on the JDK 9 API, for which we provide a Java 8 compatible alternative via reactive streams anyway.
- JDBC 4.3 compatibility (mostly sharding). We currently don't use that yet.
We're not even using internally, outside of a few integration tests. So, we'll postpone the JDK 11 *requirement* (while supporting it nonetheless) to a later release, e.g. 3.13. We'll observe market share shifts. Currently Java 11's market share is a bit of a disappointment, so making it a requirement might be premature.
- Fixed a bug when FlywayFileComparator compares non-flyway files
- Added a unit test
- Added examples to jOOQ-examples module as submodules
- Split flyway migration in one more migration file
- Check in generated sources
