Finally, jOOQ has added support for another database, and a very
promising one, that is. http://www.cubrid.org is a surprisingly
original mixture of a relational and object-oriented database
where tables and classes are synonyms, so are records and
instances. The CUBRID database has a high level of compatibility
with MySQL and is aimed at MySQL users wanting more performance
for their web applications. For details, see the slides here:

jOOQ is proud to have become a CUBRID partner, looking forward
to further cooperation with CUBRID in the near future.

Apart from that, jOOQ now fully supports SQL standard INTERVAL
data types. With JDBC and JPA lacking official support for this,
jOOQ aims for becoming the tool of choice for vendor-specific
date time arithmetic. True INTERVAL data type support is given in
HSQLDB, Ingres, Oracle, Postgres databases. Besides that, CUBRID
and MySQL support INTERVAL data type arguments in functions. In
other dialects, jOOQ simulates DATEADD(), TIMESTAMPADD(),
DATEDIFF(), TIMESTAMPDIFF().

For jOOQ's OLAP friends, there is now also support for the Oracle
LISTAGG function (LIST() in Sybase, XMLAGG() in DB2, STRING_AGG()
in Postgres, GROUP_CONCAT() in CUBRID, H2, HSQLDB, MySQL).
LISTAGG is an "ordered aggregate function", meaning that the
aggregation is done using a specific ordering. Keep an eye out
for more such function support in future versions.

With this version, jOOQ attempts to follow versioning rules
imposed by semantic versioning: http://semver.org/
There will be 1 minor release per month, and a couple of patch
releases per year, depending on popular demand

The main improvements for this release include

The possibility of providing jOOQ with a custom type mapping.
You can now define your own Converter types that are used by
jOOQ to map a database's SQLDataTypes to your custom types.
This is particularly useful for Java's enums. Read more about
custom converters in the manual:
http://www.jooq.org/manual/ADVANCED/CustomTypes/

There are a lot of new runtime configuration options to control
the SQL style of SQL rendered by jOOQ. You can now specify
whether table/column names should be quoted / capitalised /
lower-cased, whether SQL keywords should be capitalised or not,
etc...

The handling of NULL has been improved in favour of using jOOQ
as a SQL builder library (e.g. along with Spring for execution)
NULL is no longer inlined, but bound as a variable.

Apart from that, another long-requested feature is now fully
implemented: The GeneratorStrategy, allowing for custom naming
strategies in generated source code. This will allow for
generating custom table / record class name prefixes / suffixes,
as well as overriding the default behaviour for rendering UPPER,
lower and CamelCase artefacts. See the manual for details:

This release focuses on increased compatibility between various
SQL dialect integrations as far as ARRAY and JOIN support is
concerned:

ARRAY types are only available in H2, HSQLDB, Oracle, Postgres.
Nevertheless, they can be somewhat simulated in other dialects
using nested selects with UNION ALL. Increased compatibility
leads to a nicer API, where ARRAYs are used along with ALL/ANY
quantifiers, for instance.

JOIN syntaxes can be quite powerful in SQL. Apart from
simulating NATURAL JOIN, JOIN USING clauses, as well as a
synthetic &quot;KEY JOIN&quot; syntax, jOOQ now also supports nesting
JOIN expressions to create more complex table sources. See a
recent blog post on the subject here:

Test cases

This is a maintenance release for jOOQ 2.0. The main improvements
include

The whole jOOQ API is now annotated with a new org.jooq.Support
annotation to help you assess whether a certain SQL clause is
available in your database or not. This is particularly useful
when your application should support several databases at once
(e.g. MySQL, Postgres, Oracle)

The Oracle PIVOT clause is now formally supported for advanced
statistical queries in Oracle. This clause will be simulated in
other dialects in the future.

The DATE data type can be mapped to TIMESTAMP. This important
when you query a legacy Oracle database, where DATE columns
can also contain time information

Several convenience methods have been added for more fluent
syntax, when using plain SQL result queries, subqueries as
tables, or when unnesting arrays in ANY() and ALL() quantifiers

Further type mapping support is still experimental. An official
cooperation with MinuteProject for source code generation is
being analysed. With MinuteProject, many source code generation
issues could be addressed centrally, as MinuteProject specialises
in source code generation:

There is now also experimental support for a custom type mapping.
This mapping allows to rewrite data types at code generation time
as well as to specify custom enum data types (e.g. boolean Y/N).
Not all integration tests run smoothly for custom data types,
hence, this feature is not yet fully supported.

Test cases

This release is a fresh start in many areas of jOOQ, adressing
issues that have been requested by users for a long time. These
release notes docment the most important changes, a detailed
upgrade guide, as well as the detailed list of improvements.

Most important changes

The API became more static. This applies to many Factory
methods, such as val(), literal(), as well as to many Field
methods that have been moved over to the Factory. For example,
when before, you wrote this using &quot;postfix function notation&quot;:

NAME.replace(" ", "_").trim()

you will now write (just as in SQL):

trim(replace(NAME, " ", "_"))

Using static imports of Factory.*, jOOQ makes SQL look even
more like SQL. The current "postfix notation" is maintained for
backwards compatibility.

By default, jooq-codegen will now generate a "dynamic" meta
model as opposed to the existing static one. Generated tables
covariantly override the as(String) aliasing method, leading
to a much more convenient aliasing style. When before, you
wrote:

Exceptions are no longer checked. When previously, the DB's
SQLException was propagated to client code, there is now an
unchecked DataAccessException hierarchy, similar to that of
Spring. This will eventually give way to a standardised error
handling abstraction, in future developments.

Window functions are now constructed from their underlying
aggregate functions just like in SQL. For example:

sum(AMOUNT)
sum(AMOUNT).over().partitionBy(ACCOUNT)

This makes for a more concise API, especially when considering
future extensions, such as Oracle's KEEP (DENSE_RANK FIRST...)
syntax.

More type safety has been introduced regarding various places
where generic &lt;R extends Record&gt; and &lt;T&gt; types are involved.
This is especially true for INSERT / UPDATE / DELETE statements

Sequences now also have a <T> type

Unsigned number types are now supported in those databases that
use them. Unsigned numbers are implemented in jOOU, a spin-off
open source project. For convenience, this library is
&quot;internalised&quot; into jOOQ, to avoid adding a dependency

Upgrade instructions:

Various of the above changes are incompatible with jOOQ 1.x. In
order to upgrade, please be aware of the following pitfalls:

The schema needs to be re-generated.

Much of the post-fix function notation is replaced by static
methods in the Factory. Today's org.jooq.Field API is
maintained in jOOQ 2.0, for backwards compatibility. It will
be removed, eventually, though. Expect some incompatible
changes, where window functions are involved

Some Factory instance methods (such as val(), literal()) are
now static. They are compatible, but may cause compiler
warnings.

The meta model is now an instance model by default. If you
prefer the static meta model, you can configure this in your
jooq-codegen configuration.

SQLException is no longer part of the API. This can cause
compiler issues, in particular when extending jOOQ

Some utility classes have moved to org.jooq.tools

Should these incompatibilities be too significant for your
project, you can still stay on the 1.x branch, which will be
maintained for a while. Be aware that upgrading might be more
difficult, later, though.

This is a maintenance release for the 1.x branch. Developments
on this branch will stop after version 1.6.9. Only important bug
fixes are merged to this branch. Developments for release 2.0
have started.

The most important functionality in release 1.6.9 is the newly
added support for JDBC batch operations. You can now batch
execute several queries.

The main improvement of this release is the re-design of the
stored procedure / function API. With 12 supported RDBMS, which
all have their own idea about what is a stored procedure and what
is a stored function, it has proven to be a better design, to
unite them in one single type: org.jooq.Routine. A routine can
have a return value as well as OUT parameters. It can be embedded
in SQL and used as a field or a table.

This means, you will need to re-generate your database schema,
when upgrading to jOOQ 1.6.8. After re-generation, you'll need to
fix your client code. These are the package changes:

[generated.package].procedures > [generated.package].routines

[generated.package].functions > [generated.package].routines

[generated.package].Procedures > [generated.package].Routines

[generated.package].Functions > [generated.package].Routines

Oracle generated packages are not re-located. With these
improvements, using stored procedures and functions becomes even
more reliable, especially when cursor types are involved. Read
more about the rationale behind this change:

This release finally adds a loader for CSV data to jOOQ. You can
now load CSV data using a simple fluent API, configuring error
handling, duplicate behaviour and transaction handling, as well
as various CSV parameters.

This release also changes the way generated keys are retrieved
after INSERT's. Instead of (potentially inconsistently) running
SELECT MAX(pk) immediately after the INSERT, Postgres' INSERT..
RETURNING clause is used (or simulated), in a single statement.

This release ships with a couple of useful concepts inspired by
other frameworks. These are:

selecting into custom POJO's. Results can be mapped to POJO's
by convention or using JPA @Column annotations

selecting into custom callbacks. This is already a wide-spread
practice in Spring JdbcTemplates.

selecting long-running queries asynchronously. This idea has
been inspired by the Avaje Ebean framework

Apart from these changes and some bugfixes, the internal API has
been completely re-designed. The idea here is that query
rendering and variable binding are even faster (less String
objects), more extensible and more accurate. This is a pre-
requisite for many future developments with even more complex SQL
statements, such as for instance CTE's (Common Table Expressions)

API changes (backwards-incompatible)

Change internal QueryPart rendering and binding API to use
Configuration and Context as callback parameters. If you
use CustomField or CustomCondition, please correct your
implementations accordingly. Other parts of the API should
not be affected

This is mainly a maintenance release with lots of bugfixes,
mostly around code generation, plain SQL tables, and data types.
Please note that generated source code may contain incompatible
changes due to #639 (see below for details)!

Apart from that, project CURSOR is advancing and it is now
possible to unnest arrays into tables. See this article for
details about where jOOQ is heading with project CURSOR:

Project CURSOR where jOOQ finally supports various RDBMS's TABLE,
CURSOR, and REF CURSOR data types. This is especially useful when
those types are returned from stored procedures and functions.
Cursors are simply mapped to jOOQ Result<Record> types and can
thus be used like regular table results

Project EXPORT aims at exporting data from the database in
various serialisable formats, such as XML, CSV, HTML, Text, JSON.
This project will be continued in the future, to also
deserialise from (some of) these data streams. This will allow
for easy transport of jOOQ Result<?> types over the net.

Project CODEGEN has finally been started. Many improvements
suggested by jOOQ users will be implemented in the next releases.
In this release, important fixes have been made to prevent
compilation errors in generated artefacts.

In this release, the PORTABILITY project has been implemented.
Finally, the SQLDialect has been removed from most generated
artefacts (Schema, Table, Field, Sequence, etc). Also, the
constructing Factory is not referenced by its created QueryParts
anymore, unless this is really necessary (Query objects, UDT's,
ARRAY types). This leads to higher compatibility between schemata
of different databases, e.g. if users want to use an HSQLDB
development and Oracle productive database.

Unfortunately, this means that the way stored procedures are
called had to be changed. This is an API break that could not be
avoided. The pre-1.6.1 StoredObject.execute(Connection) method
is deprecated and will be removed in the future. It has been
replaced by StoredObject.execute(Configuration)

In addition to this project, many more window functions are now
supported, as well as the Oracle-specific CONNECT BY clause for
recursive queries.

Apart from supporting various additional standard and non-
standard JOIN constructs, there is now also full support for the
SQL standard MERGE statement and MySQL's ON DUPLICATE KEY variant
thereof. A great number of API enhancements have been added,
which improve the usability of jOOQ. The Ingres database is now
also supported.

This version ships with lots of new functionality. Finally, the
DSL-style API has been extended to CRUD operations (INSERT,
UPDATE, DELETE)! Also, support for the TRUNCATE TABLE statement
has been added.

The most important new features include the support for SQL:2003
standard window functions, which are available in most major
RDBMS. Additionally, basic function support has been widely
extended.

Finally, jOOQ now supports two important new RDBMS:
SQL Server and Sybase!

Apart from this great enhancement, there is now also full support
for the non-SQL standard LIMIT clause, even in dialects where the
LIMIT clause is not supported natively (especially Oracle, but
also DB2, SQL Server and Sybase, which have limitations). jOOQ
simulates LIMITs by rendering nested selects filtering on ROWNUM
(Oracle) or on ROW_NUMBER() (DB2, SQL Server and Sybase).

Other interesting additions are an increasing support for native
mathematical functions. More function support will be added in
future versions.

This is the first release built with support of Maven thanks to
the help of some jOOQ users!

The main new features in this release are the improved support
for serialisation/deserialisation of jOOQ objects through use of
the newly introduced "Attachable" interface.

If using log4j or the newly supported slf4j logging framework
in debug/trace mode, there is the possibility to log query
building/execution time statistics.

Apart from these new features, fixes were mainly done in the
fields of type casting, HSQLDB 2.1 upgrade support, stored
procedures with OUT, IN/OUT parameters. Please upgrade, if you
are using any of those features.

If you extend jOOQ as a base implementation for source code
generation, be aware of the fact, that the jOOQ-codegen is
currently undergoing major changes. Expect the code generation
API to stabilise again in one of the next releases.

The most important improvement is ticket #90, by which lazy
fetching and iteration over data is now supported. jOOQ lets you
keep a reference to a Cursor that has an open JDBC ResultSet, to
fetch data from on-the-fly.

A few major code generation bugs were reported where the
generated code may cause ambiguity due to an inconsistent API.
This means that you will have to re-generate your schema after
upgrading to version 1.5.6. Some of your code may not compile
anymore, after this upgrade.

Feature #243 required a minor API change in the base classes of
generated source code. This means you have to re-generate all
your jOOQ artifacts in order to migrate to 1.5.4. The artifacts
themselves should be regenerated in a compatible way, such that
your client code should not be affected. If this is not the case,
please report a ticket here:

Apart from the Derby RDMBS and some new data type support, there
have been many new convenience methods added all over the API.
For instance, if type-safety is not really a requirement, there
are lots of possibilities to use plain SQL directly in the DSL.
In that case, data can be accessed from Record, Results, not only
through Field<?>, but also through field names or indexes.