Digest for jooq-user@googlegroups.com - 10 updates in 4 topics

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Digest for jooq-user@googlegroups.com - 10 updates in 4 topics

http://groups.google.com/group/jooq-user/topics mailing list
Robert Mattler <[hidden email]>: Oct 04 06:20AM -0700

Upgraded to 3.10 and the code generation is creating
 
private OffsetDateTime createdOn;
 
 
This breaks everything in the front end application since it doesn't know
how to handle OffsetDateTime.
 
 
Added dateAsTimestamp but this effected the dates. Just want the
timestamps back. Thanks in advance.
 
 
<configuration>
<generator>
<database>
<dateAsTimestamp>true</dateAsTimestamp>
</database>
</generator></configuration>
 
 
Using PostgreSQL 9.6.2.
Lukas Eder <[hidden email]>: Oct 04 03:30PM +0200

Hi Robert,
 
Thanks for your message. Where did you upgrade from? And what's your
configuration for <javaTimeTypes/>? Note that <dateAsTimestamp/> is there
to indicate that (mostly Oracle's) DATE types should be generated as
TIMESTAMP types.
 
We've added JSR-310 support in jOOQ 3.9. The data type TIMESTAMP WITH TIME
ZONE is now mapped to OffsetDateTime. It was erroneously mapped to
Timestamp before that, although before supporting Java 8 and JSR-310, there
wasn't really any good alternative.
 
You can always make use of <forcedType/> to rewrite data types for any
columns:
https://www.jooq.org/doc/latest/manual/code-generation/codegen-advanced/codegen-config-forced-types
 
I hope this helps
Lukas
 
Robert Mattler <[hidden email]>: Oct 04 08:30AM -0700

I used the forced types to fix my problem. I was trying to avoid that
since every time I add a "timestamp with time zone" I have to remember to
add it to my code generation pom.xml.
 
Thanks for your help and quick response.
 
 
<forcedTypes>
 
<forcedType>
 
<name>TIMESTAMP</name>
 
<expression>
created_on|last_modified_on|fax_response_time|effective_date|assigned_on|transaction_posted_date|transaction_created_date|transaction_deposit_date|time_stamp|created_date
</expression>
 
<types>.*</types>
 
</forcedType>
 
</forcedTypes>
 
 
 
On Wednesday, October 4, 2017 at 9:30:42 AM UTC-4, Lukas Eder wrote:
Lukas Eder <[hidden email]>: Oct 04 05:53PM +0200

Hi Robert,
 
Two things:
 
1. Why not just match columns based on their types? You can specify
<types>(?i:timestamp with time zone)</types>
2. I'm curious why you're doing this in the first place. The
java.sql.Timestamp data type does not have any time zone information
associated with it. The PostgreSQL TIMESTAMP WITH TIME ZONE type is in UTC.
This means that timestamps are converted to local time (the one of your
JDBC client, not the server time, since the server uses TIMESTAMP WITH TIME
ZONE). To me, this looks like a nasty bug waiting to happen... I mean, why
not just use TIMESTAMP in the server also?
 
Best Regards,
Lukas
 
[hidden email]: Oct 04 02:56AM -0700

Good day!
 
I didn't find the way to aggregate json with jooq.
 
my schema looks like:
 
CREATE TABLE IF NOT EXISTS usage (
time TIMESTAMP NOT NULL,
metric TEXT NOT NULL,
account TEXT NOT NULL,
usage DOUBLE PRECISION NOT NULL,
data JSONB,
events JSONB,
unit TEXT
);
 

select query:
 
SelectQuery select = db.createSelectFrom(Usage.TABLE, Usage.METRIC_FIELD, Usage.ACCOUNT_FIELD, sum(Usage.USAGE_FIELD),
inline(new Timestamp(time_from)), inline(new Timestamp(time_to)), Usage.UNIT_FIELD, Usage.DATA_FIELD,
groupConcat(Usage.EVENTS_FIELD));
 
 
what at the end corresponds to the query:
 
select
"metric",
"account",
sum("usage"),
timestamp '1970-01-01 00:00:00.0',
timestamp '2019-08-22 05:15:37.0',
"unit",
"data",
array_agg("events")
from "usage"
where "time" between timestamp '1970-01-01 00:00:00.0' and timestamp
'2019-08-22 05:15:37.0'
group by
"metric",
"account",
"unit",
"data"
 
 
but in fact I need not array_agg("events") but json_agg("events"). Can it
be handled by JOOQ?
 
best,
Oleksii
Lukas Eder <[hidden email]>: Oct 04 12:13PM +0200

Hi Oleksii,
 
jOOQ currently doesn't support any JSON data types out of the box because
there's no standard JSON API in the JDK (yet). But you can easily work
around this limitation by using jOOQ's plain SQL API:
https://www.jooq.org/doc/latest/manual/sql-building/plain-sql
 
And perhaps a custom data type binding, if you want to work with some third
party JSON library:
https://www.jooq.org/doc/latest/manual/sql-building/queryparts/custom-bindings
 
Let me know if you need any specific help with that
Thanks,
Lukas
 
[hidden email]: Oct 04 04:26AM -0700

Thank you, Lukas!
 
The workaround with API quickly solved my issue!
 
many thanks,
Oleksii
 
--
Lukas Eder <[hidden email]>: Oct 04 11:49AM +0200

Hi Edgar,
 
Thanks for your message.
 
I don't think that the "H2 in PostgreSQL mode" really goes "all in" on the
PostgreSQL mode, including switching all the dictionary views to what would
be expected in PostgreSQL. Instead, it simply accepts PostgreSQL style SQL
query syntax.
 
So, the correct approach here would be to turn off PostgreSQL mode when
reverse engineering the schema with jOOQ (because the PostgreSQL mode is no
longer useful, once you've loaded the schema), and to use the H2Database
instead of the PostgresDatabase, like with any other ordinary H2 schema.
 
Note that since jOOQ 3.10, we now have a DDLDatabase for the code generator
as well, which uses jOOQ's new parser internally to reverse engineer any
dialect:
https://www.jooq.org/doc/latest/manual/code-generation/codegen-ddl
 
It internally applies a set of migration scripts (translated from any
dialect to H2) to a fresh, in-memory H2 database, and then reverse
engineers it again. Perhaps that works for you. We'd be very happy to get
any feedback on this new feature.
 
I hope this helps,
Lukas
 
[hidden email]: Oct 03 09:16PM -0700


> I am facing the following issue:
 
lokesh@lokesh-MS-7996:~/vertx$ npm start
 
> grey-bshlv@ start /home/lokesh/vertx
> vertx run server.js
 
Start Server
Succeeded in deploying verticle
Loading Tables
java.lang.RuntimeException: java.lang.ClassNotFoundException:
org.jooq.impl.DefaultConfiguration
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:397)
at
jdk.nashorn.internal.scripts.Script$Recompilation$14$2235AAAAA$\^eval\_.L:33#_load(null:113)
at
jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33#doRequire(null:154)
at
jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:645)
at
jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at
jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:1294)
at
jdk.nashorn.internal.scripts.Script$Recompilation$3$4049AAA$\^eval\_.L:33#Require(null:120)
at
jdk.nashorn.internal.scripts.Script$Recompilation$18$2109A$\^eval\_.L:33#Module#require(null:68)
at
jdk.nashorn.internal.scripts.Script$Recompilation$208$57AAAAA$\^eval\_#88\!17\^eval\_.L:1(/home/lokesh/vertx/verticles/tables/tables.js:5)
at
jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:647)
at
jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
at
jdk.nashorn.internal.scripts.Script$Recompilation$14$2235AAAAA$\^eval\_.L:33#_load(null:113)
at
jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33#doRequire(null:154)
at
jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:645)
at
jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at
jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:1294)
at
jdk.nashorn.internal.scripts.Script$Recompilation$3$4049AAA$\^eval\_.L:33#Require(null:120)
at
jdk.nashorn.internal.scripts.Script$Recompilation$18$2109A$\^eval\_.L:33#Module#require(null:68)
at
jdk.nashorn.internal.scripts.Script$Recompilation$206$15777A$\^eval\_#88\!17\^eval\_.L:1#L:440(/home/lokesh/vertx/server.js:443)
at
jdk.nashorn.internal.scripts.Script$Recompilation$203$3127A$\^eval\_#88\!17\^eval\_.L:1#WorkerExecutor#executeBlocking#L:74(vertx-js/worker_executor.js:75)
at io.vertx.core.Handler$$NashornJavaAdapter.handle(Unknown Source)
at
io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:271)
at io.vertx.core.impl.TaskQueue.lambda$new$0(TaskQueue.java:60)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException:
org.jooq.impl.DefaultConfiguration
at
jdk.nashorn.internal.runtime.NativeJavaPackage.classNotFound(NativeJavaPackage.java:162)
at
jdk.nashorn.internal.scripts.Script$Recompilation$217$57AAAAA$\^eval\_#88\!17\^eval\_.L:1(/home/lokesh/vertx/verticles/postgres-functions.js:3)
at
jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:647)
at
jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
... 26 more
Any idea how could I fix this issue ?
Regards
Lukas Eder <[hidden email]>: Oct 04 09:31AM +0200

Hi Lokesh,
 
Thanks for your report. I'm not sure this is the same issue as the one
originally reported. In any case, it looks as though jOOQ is not on your
class path. You'll have to set up the dependencies correctly.
 
From what you posted so far, I can't say what went wrong, though.
 
Thanks,
Lukas
 
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].