jOOQ3 inserting PGobject fails

[Peter Cooner]

Using jOOQ 3 RC1

I can select any PGobject from the database, but when I try to reinsert the PGobject it fails saying:

org.jooq.exception.SQLDialectNotSupportedException: Type class org.postgresql.util.PGobject is not supported in dialect null

at org.jooq.impl.DefaultDataType.getDataType(DefaultDataType.java:640)

at org.jooq.impl.Factory.mostSpecific(Factory.java:6857)

at org.jooq.impl.Factory.val(Factory.java:6833)

at org.jooq.impl.Factory.val(Factory.java:6803)

at org.jooq.impl.Utils.field(Utils.java:441)

at org.jooq.impl.AbstractStoreQuery.addValue(AbstractStoreQuery.java:101)

at org.jooq.impl.InsertImpl.addValue(InsertImpl.java:284)

at org.jooq.impl.InsertImpl.values(InsertImpl.java:263)

at org.jooq.impl.InsertImpl.values(InsertImpl.java:147)

at org.jooq.impl.InsertImpl.values(InsertImpl.java:84)

at gis.Main.main(Main.java:89)

337 [main] INFO gis.Main  - End

Previously (2.6.X) this worked, but am I bumping into unsupported feature land?

-- 

Pete

[Lukas Eder]

Can you show the source code that lead to this issue?
Note, there is another thread about PostGIS support and how jOOQ
doesn't yet fully support this...

2013/2/24 Peter Cooner <petr...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "jOOQ User Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jooq-user+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Peter Cooner]

It doesn't matter what sort of PGobject it is, none of them work.

Here is an example:

PGobject pgo2 = new PGInterval();

f.insertInto(TEST, TEST.VAL)

        .values(pgo2)

        .execute();

Specifically I noticed this not working with any of the PostgreSQL geo types, or the PostGIS geo types, or the HStore types.

Another interesting thing, the 'interval' type is detected by jOOQ (unlike hstore, or geos)

TableField<TrackPositionRecord, Object> VAL = createField("val", DefaultDataType.getDefaultDataType("interval"), this);

Then if I then cast the type...

PGobject pgo2 = new PGInterval();

f.insertInto(TEST, TEST.VAL)

        .values(cast(pgo2.toString(), TEST.VAL))

        .execute();

This works!

- Executing query          : insert into "public"."track_position" ("val") values (cast(? as interval))

- -> with bind values      : insert into "public"."track_position" ("val") values (cast('0 years 0 mons 0 days 0 hours 0 mins 0.00 secs' as interval))

But any other types remain undetected and are "USER-DEFINED" modifying this string to "geometry" or "hstore" allows for these sort of dirty tricks.

Maybe you should consider the ability to pass in a string-type to cast so that dirty tricks could be used?

.values(cast(pgo2.toString(), "interval"))

I haven't figured out how to pass these oddball types into Postgres as a string otherwise, any time I send a geometry as a string it complains I'm trying to cast the geom as a varchar type instead. :-/

[Peter Cooner]

Here we go, hacks abound.

DataType<Object> geometry = new DefaultDataType<>(

        SQLDialect.POSTGRES, SQLDataType.OTHER, "geometry");

f.insertInto(TRACK_POSITION, TRACK_POSITION.GEOM_POS)

        .values(cast(PGgeomPoint.toString(), geometry))

        .execute();

- Executing query          : insert into "public"."track_position" ("geom_pos") values (cast(? as geometry))

- -> with bind values      : insert into "public"."track_position" ("geom_pos") values (cast('SRID=4326;POINT(0 0)' as geometry))

This is what I end up doing to insert PostGIS points until PGobjects can be inserted again.

-- 

Pete

[Lukas Eder]

Hi Peter,

Thanks a lot for showing these hacks. Clearly, this isn't how jOOQ
should be used in the long run ;-)

But it helps understanding what parts of the code generator and the
core will need to be adapted to finally support these PG* types. It
looks like using the String serialisation of these types, with the
appropriate cast, is a good way to handle such bind values.

For now, PG* types can probably be identified through reflection, in
order to avoid creating compile-time dependencies within jOOQ's core
module. In a future version, I might think about adding new modules
for vendor-specific feature support, exposing PG* type converters,
converting <String, PG*>

I will increase the priority of #982, as formal support for these
Postgres extensions have now been requested many times on the user
group:
https://github.com/jOOQ/jOOQ/issues/982

I think that jOOQ 3.1 will certainly be a good milestone to implement
these things. Feel free to post any other findings that you may have
in the mean time.

Cheers
Lukas

2013/2/25 Peter Cooner <petr...@gmail.com>:

[Peter Cooner]

Do you suppose you could give me a rundown of whats going on internally for these objects on inserts? I would much rather be using Records than these custom insert statements with casts. I keep running into problems out of jOOQ, NullPointerExceptions (no idea) and other things.

If I may say, what we really need is a proper "ANY" type that can be used with records, basically any time jOOQ runs into "USER-DEFINED" just use the magic ANY type and ignore all the type BS Java side as the user is clearly trying to do something crazy. There are already several checks for UDT, cursor type, and such in the type system, but the current Postgres ANY type is of type Object (SQL type OTHER) and then jOOQ insists incorrectly somewhere, instead of just passing it through to the JDBC engine.

[Peter Cooner]

Bleh.

Allow me to be more clear headed about this and less... uh confused. :-)

The exception from before:

org.jooq.exception.SQLDialectNotSupportedException: Type class org.postgis.PGgeometry is not supported in dialect null

at org.jooq.impl.DefaultDataType.getDataType(DefaultDataType.java:640)

at org.jooq.impl.Factory.mostSpecific(Factory.java:6857)

at org.jooq.impl.Factory.val(Factory.java:6833)

at org.jooq.impl.Factory.val(Factory.java:6803)

at org.jooq.impl.Utils.field(Utils.java:441)

at org.jooq.impl.UpdatableRecordImpl.addValue(UpdatableRecordImpl.java:254)

at org.jooq.impl.UpdatableRecordImpl.addValue(UpdatableRecordImpl.java:261)

at org.jooq.impl.UpdatableRecordImpl.addChangedValues(UpdatableRecordImpl.java:245)

at org.jooq.impl.UpdatableRecordImpl.storeInsert(UpdatableRecordImpl.java:162)

at org.jooq.impl.UpdatableRecordImpl.store(UpdatableRecordImpl.java:143)

at gis.Main.main(Main.java:123)

The code:

    private static <T> DataType<T> mostSpecific(T value, DataType<T> dataType) {

        if (value != null) {

            Class<?> valueType = value.getClass();

            Class<T> coercionType = dataType.getType();

            if (valueType != coercionType && coercionType.isAssignableFrom(valueType)) {

                return (DataType<T>) DefaultDataType.getDataType(null, valueType);

            }

        }

        return dataType;

    }

It seems to me I don't understand this function - if we have a SQLDataType.OTHER here then the type is always assignable, which leads us into getDataType() which will always throw an exception.

If the type is OTHER, then we really shouldn't be trying to "find" any type, just returning type OTHER and be done with it?

[Lukas Eder]

> Do you suppose you could give me a rundown of whats going on internally for
> these objects on inserts?

Hmm, the behaviour is rather unexpected if it isn't covered by jOOQ's
integration test. I mean, you can probably assume that
PreparedStatement.setObject() will be called by jOOQ to pass those PG*
objects to JDBC. But there's no guarantee, as variable binding across
all 14 SQL dialects has become a bit tricky inside of jOOQ.

I'm not even sure if jOOQ converters could be used to add more
certainty about jOOQ's behaviour here, as the JDBC data type would
probably still be "Object" - I haven't tried this yet, though.

> I would much rather be using Records than these
> custom insert statements with casts. I keep running into problems out of
> jOOQ, NullPointerExceptions (no idea) and other things.

Yes, but unfortunately, I really can't give you any hints towards a
sound solution yet.

> If I may say, what we really need is a proper "ANY" type that can be used
> with records, basically any time jOOQ runs into "USER-DEFINED" just use the
> magic ANY type and ignore all the type BS Java side as the user is clearly
> trying to do something crazy. There are already several checks for UDT,
> cursor type, and such in the type system, but the current Postgres ANY type
> is of type Object (SQL type OTHER) and then jOOQ insists incorrectly
> somewhere, instead of just passing it through to the JDBC engine.

OK, I wasn't aware of this "USER-DEFINED" pseudo-type. You're right,
"ANY" would be a better match, here. Can you provide me with some
minimal DDL to reproduce "USER-DEFINED"? I can then try to at least
make *some* things work before PG* types are formally supported

Cheers
Lukas

[Lukas Eder]

> Allow me to be more clear headed about this and less... uh confused. :-)

Hehe

> It seems to me I don't understand this function - if we have a
> SQLDataType.OTHER here then the type is always assignable, which leads us
> into getDataType() which will always throw an exception.
> If the type is OTHER, then we really shouldn't be trying to "find" any type,
> just returning type OTHER and be done with it?

Hmm, that mostSpecific() method was explicitly introduced in order to
"downcast" a DataType such as OTHER to a more specific data type, if
such "more specific type information" is available. Whew. This was
issue #2007 as stated in the method's Javadoc:
https://github.com/jOOQ/jOOQ/issues/2007

A use-case for this is the following predicate:
create.fieldByName("TEST_COLUMN").lessThan(now)

The left-hand side of the predicate lacks type information
(Field<Object>), so the bind value from the right-hand side should not
be OTHER, but some more specific data type.

But still, there should be no NullPointerException. I have registered
#2267 for this. I'll try to reproduce this and see if it can be fixed,
soon...
https://github.com/jOOQ/jOOQ/issues/2267

Cheers
Lukas

[Peter Cooner]

Any time you're using one of PostgreSQL's extensions (hstore, PostGIS, etc) you'll run into this problem

For PostgreSQL 9.1+ you can easily import them into your DB for example:

DROP DATABASE IF EXISTS testdb;

CREATE DATABASE testdb;

\c testdb;

BEGIN;

CREATE EXTENSION postgis;

CREATE EXTENSION hstore;

CREATE SEQUENCE tp_sequence;

CREATE TABLE tp (

    position_id bigint default nextval('tp_sequence'),

    text varchar,

    val1 interval,

    val2 box,

    val3 hstore,

    geom_pos geometry(Point, 4326, 2),

    PRIMARY KEY(position_id)

);

COMMIT;

Then the java code looks like

Point point = new Point(0, 0);

point.setSrid(4326);

PGgeometry PGgeomPoint = new PGgeometry(point);

TpRecord tp = new TpRecord();

tp.setGeomPos(PGgeomPoint);

tp.attach(create);

tp.store();

[Lukas Eder]

Great, thanks for the DDL / Java code. I'll keep you posted

2013/2/25 Peter Cooner <petr...@gmail.com>:

[Peter Cooner]

Yeah I was just reading this code change log about this...

Is there a missing case here? Basically, I see this as a difference of an unresolved type vs the type OTHER (which is specifically unspecified - hahah).

Maybe you really need to have something like:

SQLDataType.USERDEFINED

SQLDataType.UNRESOLVED

Instead of overloading SQLDataType.OTHER.

The NPE was coming out of my trying to use create.insertInto query parts instead of a Record.store() call. Basically, I have to cast the pgo.toString() result to a type in the query right now, and the code is super bad.

So its critical that I be able to pass the PGobject through to JDBC, unmolested by jOOQ - to put it bluntly.

Is there any way to get the statement a store would make, or approximate it? I'll go look into doing something like create.insertInto(TABLE).values(Record).toSQL() without binding the variables or something... Then I could build the batch query myself using JDBC. Then I could use Record.intoArray() or something to build the parameter list....

 

[Lukas Eder]

It turns out that this issue was rather easy to fix. This SQLDialectNotSupportedException shouldn't be thrown from the mostSpecific() method:
https://github.com/jOOQ/jOOQ/commit/24254e039e5e9d0e69af2146e9953defa3df4db5

Unfortunately, I had released jOOQ 2.6.3 today, so this fix will have to wait for 2.6.4 to be published.

> Is there a missing case here? Basically, I see this as a difference of an
> unresolved type vs the type OTHER (which is specifically unspecified -
> hahah).
>
> Maybe you really need to have something like:
>
> SQLDataType.USERDEFINED
> SQLDataType.UNRESOLVED
>
> Instead of overloading SQLDataType.OTHER.

What would be the added value of these types? To me, java.sql.Types.OTHER is the most appropriate JDBC type for what you call unresolved / userdefined:
http://docs.oracle.com/javase/7/docs/api/java/sql/Types.html#OTHER

> The NPE was coming out of my trying to use create.insertInto query parts
> instead of a Record.store() call. Basically, I have to cast the
> pgo.toString() result to a type in the query right now, and the code is
> super bad.
>
> So its critical that I be able to pass the PGobject through to JDBC,
> unmolested by jOOQ - to put it bluntly.

Yes, I got that now. You can stop instisting :-) The NPE is a bug, which was easy to fix even before introducing formal PG* support...

> Is there any way to get the statement a store would make, or approximate it?
> I'll go look into doing something like
> create.insertInto(TABLE).values(Record).toSQL() without binding the
> variables or something... Then I could build the batch query myself using
> JDBC. Then I could use Record.intoArray() or something to build the
> parameter list....

Yes, you can use Query.getSQL() and Query.getBindValues() from an INSERT statement:

http://www.jooq.org/javadoc/latest/org/jooq/Query.html#getSQL()

http://www.jooq.org/javadoc/latest/org/jooq/Query.html#getBindValues()

You can also "intercept" the query that would be rendered by Record.store(), via ExecuteListeners:
http://www.jooq.org/doc/3.0/manual/sql-execution/execute-listeners/

Just throw an exception once the SQL statement has been rendered, preventing its execution. org.jooq.impl.BatchCRUD has a QueryCollector, which roughly looks like this:

    /**
     * Collect queries
     * <p>
     * The query collector intercepts query execution after rendering. This
     * allows for rendering SQL according to the specific logic contained in
     * TableRecords without actually executing that SQL
     */
    private static class QueryCollector extends DefaultExecuteListener {

        /**
         * Generated UID
         */
        private static final long serialVersionUID = 7399239846062763212L;

        @Override
        public void renderEnd(ExecuteContext ctx) {
            throw new QueryCollectorException(ctx.sql(), ctx.query());
        }
    }

    /**
     * A query execution interception signal
     * <p>
     * This exception is used as a signal for jOOQ's internals to abort query
     * execution, and return generated SQL back to batch execution
     */
    private static class QueryCollectorException extends RuntimeException {

        /**
         * Generated UID
         */
        private static final long serialVersionUID = -9047250761846931903L;
        private final String      sql;
        private final Query       query;

        QueryCollectorException(String sql, Query query) {
            this.sql = sql;
            this.query = query;
        }

        String getSQL() {
            return sql;
        }

        Query getQuery() {
            return query;
        }
    }


Taken from:
https://github.com/jOOQ/jOOQ/blob/master/jOOQ/src/main/java/org/jooq/impl/BatchCRUD.java

[Peter Cooner]

On Monday, February 25, 2013 11:10:23 AM UTC-5, Lukas Eder wrote:

It turns out that this issue was rather easy to fix. This SQLDialectNotSupportedException shouldn't be thrown from the mostSpecific() method:
https://github.com/jOOQ/jOOQ/commit/24254e039e5e9d0e69af2146e9953defa3df4db5

Unfortunately, I had released jOOQ 2.6.3 today, so this fix will have to wait for 2.6.4 to be published.

Not a problem, I pulled the source a long time ago.

 

What would be the added value of these types? To me, java.sql.Types.OTHER is the most appropriate JDBC type for what you call unresolved / userdefined:
http://docs.oracle.com/javase/7/docs/api/java/sql/Types.html#OTHER

Well, then OTHER works for USERDEFINED, I was really thinking of ways to avoid tripping over the unresolved type issue in #2007 on the Java side. Only thinking aloud here, not trying to say anything.

Yes, I got that now. You can stop instisting :-) The NPE is a bug, which was easy to fix even before introducing formal PG* support...

Alright, sorry, I'll let it rest.

Thank you again for the hard work.

I'd love to be able to compile and test out this change - see where that takes me.

I have pulled the code down, and read through some of the info for compiling jOOQ from source, but I'm running into problems.

I admittedly am not an Eclipse guy, so after tripping over that a lot, I tried Netbeans and think things are "compiling", except when I now run the generator tool

Feb 25, 2013 12:07:50 PM org.jooq.tools.JooqLogger info

INFO:   relations              : true

Feb 25, 2013 12:07:50 PM org.jooq.tools.JooqLogger info

INFO:   global references      : true

Feb 25, 2013 12:07:50 PM org.jooq.tools.JooqLogger info

INFO: ----------------------------------------------------------

Feb 25, 2013 12:07:50 PM org.jooq.tools.JooqLogger info

INFO: Emptying                 : /Users/petri/Development/test4-jooq-gis/src/gis/generated

Exception in thread "main" java.lang.NoSuchMethodError: org.jooq.impl.Factory.val(Ljava/lang/Object;)Lorg/jooq/Field;

at org.jooq.impl.Limit.<init>(Limit.java:61)

at org.jooq.impl.SelectQueryImpl.<init>(SelectQueryImpl.java:140)

at org.jooq.impl.SelectQueryImpl.<init>(SelectQueryImpl.java:121)

at org.jooq.impl.SelectImpl.<init>(SelectImpl.java:144)

at org.jooq.impl.SelectImpl.<init>(SelectImpl.java:140)

at org.jooq.impl.Factory.select(Factory.java:248)

at org.jooq.impl.Executor.select(Executor.java:1765)

at org.jooq.impl.Executor.select(Executor.java:1802)

at org.jooq.util.postgres.PostgresDatabase.getSchemata0(PostgresDatabase.java:220)

at org.jooq.util.AbstractDatabase.getSchemata(AbstractDatabase.java:148)

at org.jooq.util.JavaGenerator.generate(JavaGenerator.java:168)

at org.jooq.util.GenerationTool.main(GenerationTool.java:257)

at org.jooq.util.GenerationTool.main(GenerationTool.java:103)

Java Result: 1

Maybe this is caused by my using NB instead, I'm not sure what NB is doing when it compiles the Mavan project or what targets its using.

Calling "mvn package" from the command line in the project / sub-project directories is only kind of successful.

[Lukas Eder]

Hi Peter,

What would be the added value of these types? To me, java.sql.Types.OTHER is the most appropriate JDBC type for what you call unresolved / userdefined:
http://docs.oracle.com/javase/7/docs/api/java/sql/Types.html#OTHER

Well, then OTHER works for USERDEFINED, I was really thinking of ways to avoid tripping over the unresolved type issue in #2007 on the Java side. Only thinking aloud here, not trying to say anything.

I see. Hmm, I'm not sure if it would change something, to have two org.jooq.DataTypes that bind to java.lang.Object. I guess there would be some cases, where it will be hard to decide, whether Object should map to OTHER, or UNRESOLVED

Looks to me like some old artefacts are lying around...? Factory.val used to return org.jooq.Field, whereas in jOOQ 3.0, it now returns org.jooq.Param. I'm not sure how this could be caused, though... 

Calling "mvn package" from the command line in the project / sub-project directories is only kind of successful.

What do you mean by "kind of successful" ? 

[Peter Cooner]

On Monday, February 25, 2013 12:46:42 PM UTC-5, Lukas Eder wrote:

What do you mean by "kind of successful" ? 

So this fails

jooq-parent$ mvn package

But

jooq-parent$ mvn package -amd

Builds, but fails on the tests with

Failed tests: 

  testInsertQuery2(org.jooq.test.BasicTest): null expected:<...(10, 'ABC', date '19[70-01-0]1')> but was:<...(10, 'ABC', date '19[69-12-3]1')>

  testMergeQuery(org.jooq.test.BasicTest): null expected:<..."."DATE1" = date '19[70-01-01' when not matched then insert ("ID1", "NAME1", "DATE1") values (1, 'name', date '1970-01-0]1')> but was:<..."."DATE1" = date '19[69-12-31' when not matched then insert ("ID1", "NAME1", "DATE1") values (1, 'name', date '1969-12-3]1')>

  testToString(org.jooq.test.ConvertTest): expected:<19[70-01-0]1> but was:<19[69-12-3]1>

Now that wouldn't produce jars, so i did some other things, eventually it pretended to compile but I got that runtime error instead. I think the jars were improperly built somehow, but maven had become confused and stopped complaining.

Once I did this

mvn install -Dmaven.test.skip=true -amd

(or mvn package -Dmaven.test.skip=true -amd)

This seemed to make a lot more real progress, and I copied over the jars, now things work - might want to add a couple of lines in the README that says something like

cd jooq-parent directory and run

$ mvn package -Dmaven.test.skip=true -amd

For us simple folk who just stick to ant scripts. :-)

Once I got the jars working I ran the PGobject test and things work now!! So thank you again.

[Lukas Eder]

Hi Peter,

Sorry for the hassle caused by Maven and the unit tests :-)

What do you mean by "kind of successful" ? 

So this fails

jooq-parent$ mvn package

Interesting

 

But

jooq-parent$ mvn package -amd

Builds, but fails on the tests with

Failed tests: 

  testInsertQuery2(org.jooq.test.BasicTest): null expected:<...(10, 'ABC', date '19[70-01-0]1')> but was:<...(10, 'ABC', date '19[69-12-3]1')>

  testMergeQuery(org.jooq.test.BasicTest): null expected:<..."."DATE1" = date '19[70-01-01' when not matched then insert ("ID1", "NAME1", "DATE1") values (1, 'name', date '1970-01-0]1')> but was:<..."."DATE1" = date '19[69-12-31' when not matched then insert ("ID1", "NAME1", "DATE1") values (1, 'name', date '1969-12-3]1')>

  testToString(org.jooq.test.ConvertTest): expected:<19[70-01-0]1> but was:<19[69-12-3]1>

Hmm, I guess some tests weren't written timezone-safely. Looks like these tests fail as you're not in CET / CEST. I should fix that

https://github.com/jOOQ/jOOQ/issues/2271

 

Now that wouldn't produce jars, so i did some other things, eventually it pretended to compile but I got that runtime error instead. I think the jars were improperly built somehow, but maven had become confused and stopped complaining.

Once I did this

mvn install -Dmaven.test.skip=true -amd

(or mvn package -Dmaven.test.skip=true -amd)

This seemed to make a lot more real progress, and I copied over the jars, now things work

Great!

 

- might want to add a couple of lines in the README that says something like

cd jooq-parent directory and run

$ mvn package -Dmaven.test.skip=true -amd

For us simple folk who just stick to ant scripts. :-)

Yes, you're right. I'm still struggling with this Maven myself, so I hear you. I'll add a section to the manual explaining how to build jOOQ:

https://github.com/jOOQ/jOOQ/issues/2270

 

Once I got the jars working I ran the PGobject test and things work now!! So thank you again.

Good to know! I'll merge this fix downstream, then, to 2.6.4 and 2.7, for those users that aren't ready to migrate to jOOQ 3.0 yet.

Please tell me if you run into any other issues / corner-cases. As you said yourself, jOOQ shouldn't "touch" any bind values that are passed in as Object/OTHER. That was the original intention, but of course, there is a lot of potential for bugs in this area, as there are few integration tests covering these "unexpected" types.

Cheers

Lukas

[Peter Cooner]

On Monday, February 25, 2013 4:39:40 PM UTC-5, Lukas Eder wrote:

Yes, you're right. I'm still struggling with this Maven myself, so I hear you. I'll add a section to the manual explaining how to build jOOQ:

https://github.com/jOOQ/jOOQ/issues/2270

 

Once I got the jars working I ran the PGobject test and things work now!! So thank you again.

Good to know! I'll merge this fix downstream, then, to 2.6.4 and 2.7, for those users that aren't ready to migrate to jOOQ 3.0 yet.

Please tell me if you run into any other issues / corner-cases. As you said yourself, jOOQ shouldn't "touch" any bind values that are passed in as Object/OTHER. That was the original intention, but of course, there is a lot of potential for bugs in this area, as there are few integration tests covering these "unexpected" types.

Happy to help.

Are there specific test corner cases that you need tests for? I have been writing jOOQ snippets here and there for my own testing.... 

[Lukas Eder]

Happy to help.

Are there specific test corner cases that you need tests for? I have been writing jOOQ snippets here and there for my own testing.... 

These two come to my mind: 

- Since you've been doing things with intervals, did you manage to use them for date/time arithmetic with jOOQ? e.g. date +/- interval, (date1, interval1) overlaps (date2, interval2), etc.

- Could you generate PostGIS stored procedures and use PG* objects with those procedures (as IN, OUT, IN/OUT parameters)?

[Lukas Eder]

But

jooq-parent$ mvn package -amd

Builds, but fails on the tests with

Failed tests: 

  testInsertQuery2(org.jooq.test.BasicTest): null expected:<...(10, 'ABC', date '19[70-01-0]1')> but was:<...(10, 'ABC', date '19[69-12-3]1')>

  testMergeQuery(org.jooq.test.BasicTest): null expected:<..."."DATE1" = date '19[70-01-01' when not matched then insert ("ID1", "NAME1", "DATE1") values (1, 'name', date '1970-01-0]1')> but was:<..."."DATE1" = date '19[69-12-31' when not matched then insert ("ID1", "NAME1", "DATE1") values (1, 'name', date '1969-12-3]1')>

  testToString(org.jooq.test.ConvertTest): expected:<19[70-01-0]1> but was:<19[69-12-3]1>

Hmm, I guess some tests weren't written timezone-safely. Looks like these tests fail as you're not in CET / CEST. I should fix that

https://github.com/jOOQ/jOOQ/issues/2271

This is now fixed on Github master

Cheers

Lukas

[Peter Cooner]

Cool, now "mvn package" more or less works (though I would recommend documenting still how to disable the tests) 

There were still some errors from the scala library:

[INFO] Checking for multiple versions of scala

[INFO] includes = [**/*.scala,**/*.java,]

[INFO] excludes = []

[INFO] /Users/petri/Development/jOOQ/jOOQ-scala/src/test/scala:-1: info: compiling

[INFO] Compiling 3 source files to /Users/petri/Development/jOOQ/jOOQ-scala/target/test-classes at 1361882499742

[ERROR] /Users/petri/Development/jOOQ/jOOQ-scala/src/test/scala/org/jooq/scala/example/Test.scala:45: error: object h2 is not a member of package org.jooq.scala.example

[INFO] import org.jooq.scala.example.h2.Tables._

[INFO]                               ^

[ERROR] /Users/petri/Development/jOOQ/jOOQ-scala/src/test/scala/org/jooq/scala/test/ArithmeticExpressionTest.scala:8: error: object h2 is not a member of package org.jooq.scala.example

[INFO] import org.jooq.scala.example.h2.Tables._

[INFO]                               ^

[ERROR] /Users/petri/Development/jOOQ/jOOQ-scala/src/test/scala/org/jooq/scala/test/ComparisonPredicateTest.scala:7: error: object h2 is not a member of package org.jooq.scala.example

[INFO] import org.jooq.scala.example.h2.Tables._

[INFO]                               ^

[ERROR] three errors found

[Peter Cooner]

Happy to, I'll cleanup some of the snippets I wrote and post them in a day or two.

[Lukas Eder]

Cool, now "mvn package" more or less works (though I would recommend documenting still how to disable the tests) 

Great, yes, I'll do that soon.

 

There were still some errors from the scala library:

I know. I couldn't get my head around how to correctly order

1. SQL execution (setting up the sample H2 database)

2. jOOQ codegeneration

3. Running the Scala tests

Any help from the group would be greatly appreciated...

Cheers

Lukas