Thanks for your message. Let's discuss on your cross-posted question here:
https://stackoverflow.com/q/78829023/521799
On Sat, Aug 3, 2024 at 9:23 PM Shyam wrote:
> I am updating my projects from Jooq 3.14.16 to Jooq 3.19.10
> I am using codegen tool to generate Java source for jooq entities.
>
See my answer to your cross-posted question here:
https://github.com/jOOQ/jOOQ/discussions/17004
On Thu, Aug 1, 2024 at 10:31 AM Nico van de Kamp
wrote:
> I have an SQL query which is working. I want to add this to Kotlin wiht
> Jooq code. Does there exist a SQL --> JooQ converter?
>
> --
> You
Hi Humaid,
The Geometry type is there to document that this feature set exists in the
commercial editions of jOOQ. The implementation is missing from the jOOQ
Open Source Edition.
I hope this helps,
Lukas
On Wednesday, July 10, 2024, Humaid Kidwai wrote:
> Hello!
>
> Novice Java programmer
>
> * Is this general approach the right one?
>
Do also check for unique constraints on the foreign key. It's not a widely
adopted practice, but if you do encounter one, you'll know it's a 1-1
relationship (where 1 means 0..1). Other than that, I mean, it's a
heuristic. You won't have any
As an aside, you can always extend the code generator and generate "custom
code sections" like the one in your suggestion:
https://www.jooq.org/doc/latest/manual/code-generation/codegen-custom-code/
On Tue, Jul 2, 2024 at 9:38 AM Lukas Eder wrote:
> Thanks for yo
Thanks for your suggestion.
This attempts to address the underlying issue at the wrong place: the
creation of specific types of predicates, when the feature you're really
looking for is a type safe representation of a key. With such a type safe
representation, *all* the key interactions will be
egressions for kotlin
multiplatform use-cases.
On Thursday, June 20, 2024 at 4:30:51 PM UTC+2 ke...@knowledgespike.com
wrote:
> That should work. I’ll give it a go when I’m back at my computer,
>
> Kevin Jones
> KnowledgeSpike
>
>
> On Thu, 20 Jun 2024 at 14:36, Luka
Hi Bert-Jan,
I'm assuming this is a runtime query, not a code generation query? Have you
configured your Configuration with the correct (versioned) SQLDialect? jOOQ
3.19 has started supporting SQLDialect.ORACLE23AI, so if you're using an
older version (e.g. 18c), then you should configure jOOQ
Well, what about this? Why did you do this?
ext {
// use jOOQ version defined in Spring Boot
jooqVersion = dependencyManagement.importedProperties['jooq.version']
}
configurations.classpath {
// Enforce the jOOQ configuration XML schema version
resolutionStrategy.eachDependency {
if
Hi,
The answer is here:
Could not find org.jooq:jooq-codegen-gradle:3.18.17.
The plugin was first released in 3.19.0
I hope this helps.
On Fri, Jun 21, 2024 at 6:38 AM Debapriya Patra
wrote:
> Hello,
>
> I am trying to use the Jooq official codegen gradle plugin instead of a
> third party
In any case, the workaround should be to explicitly create the main source
set in your build script, yes?
On Thursday, June 20, 2024 at 10:53:52 AM UTC+2 Lukas Eder wrote:
> Thanks a lot for the reproducer, Kevin, that certainly helps save time and
> regression-test this particula
dependsOn(tasks["jooqCodegen"])
> }
>
> I want jooqCodeGen to run when I do a compile and it's the 'dependsOn'
> that's causing the issue
>
> HTH,
>
> Kevin
>
>
>
> On Wed, Jun 19, 2024 at 5:10 PM Lukas Eder wrote:
>
>> I've created this i
I've created this issue:
https://github.com/jOOQ/jOOQ/issues/16842
On Wed, Jun 19, 2024 at 6:06 PM Lukas Eder wrote:
> OK, I get it now.
>
> Before 3.19.10, we just didn't register any source sets at all, if there
> was no main source set.
>
> I'm assuming, you manuall
OK, I get it now.
Before 3.19.10, we just didn't register any source sets at all, if there
was no main source set.
I'm assuming, you manually added the output directory to a source set in
your case?
On Wed, Jun 19, 2024 at 5:06 PM Lukas Eder wrote:
> Hi Kevin
>
> May I tempt you
Hi Kevin
May I tempt you to kindly provide a reproducer
Lukas
On Wednesday, June 19, 2024, Kevin Jones wrote:
> Hi Lucas,
>
> I'm using Gradle, which I know you love!
>
> I've just tried to update my build to 3.19.10, literally by changing the
> JOOQ version number from 3.19.9 to 3.19.10 and
Version 3.17.26 - June 14, 2024
This is a 3.17 patch release with minor improvements and bug fixes
Features and Improvements
-
#16808 - Clarify EmbeddableRecord Javadoc
Bug Fixes
Thanks for your message.
At a quick glance, I'd say:
1. The error message says: no JDBC connection configured
2. You didn't correctly configure your JDBC connection
I'm afraid I don't know gradle or the third party plugin well enough to
assess whether everything is done in the right order when
apriya Patra
> 650.933.6852
>
>
> On Tue, Jun 11, 2024 at 12:04 AM Lukas Eder wrote:
>
>> Thanks for your message. We'll have gradle examples eventually in our
>> MCVE template:
>> https://github.com/jOOQ/jOOQ-mcve/issues/41
>>
>> They'll be using testcontainers too
Look into these sections:
-
https://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy/
-
https://www.jooq.org/doc/latest/manual/code-generation/codegen-matcherstrategy/
On Tuesday, June 11, 2024, 'Bernd Huber' via jOOQ User Group <
jooq-user@googlegroups.com> wrote:
> Im
;> Or, IDEA needs to be able to introspect ALL the source-sets and include
>> them in its list of sources ... not just the Java/Kotlin ones. But maybe
>> that's a big ask, for it to know what to do with *every* random sourceSet.
>>
>> HTH,
>> David.
>>
>> On T
d it should be reported.
>> Please report at https://youtrack.jetbrains.com/issues/IDEA
>>
>> Thank you in advance!
>> On Thursday 14 March 2024 at 19:49:14 UTC+1 Lukas Eder wrote:
>>
>>> Hi Kevin,
>>>
>>> Thanks for the example project. I can reproduce the issue
Thanks for your message. We'll have gradle examples eventually in our MCVE
template:
https://github.com/jOOQ/jOOQ-mcve/issues/41
They'll be using testcontainers too.
Unfortunately, until then, I can't really comment about the "best way" to
do it. (It will be very hard with gradle anyway, because
On Mon, Jun 10, 2024 at 10:12 AM Rob Sargent wrote:
> I was/am confused by this entry in OP's stack trace. Isn't that the IDE?
>
It's a library jOOQ uses for better IDE integration, especially for Kotlin
users:
https://github.com/JetBrains/java-annotations
The dependency is optional.
I hope
Rob,
On Mon, Jun 10, 2024 at 8:17 AM Rob Sargent wrote:
> On 6/9/24 06:01, Kevin Jones wrote:
>
>
>> Warning: org.jooq.impl.DSL: can't find referenced class
>> org.jetbrains.annotations.ApiStatus$Obsolete
>> Warning: org.jooq.impl.DSL: can't find referenced class
>>
Hi Kevin,
Thanks for your message.
The mandatory and optional dependencies are summarised in the
module-info.java file here (for reasons we might never truly know, the
keyword is "static", not "optional"):
https://github.com/jOOQ/jOOQ/blob/main/jOOQ/src/main/java/module-info.java
You'll find
What performance impact are you fearing, specifically? I mean, the
Configuration hosts the reflection cache for those into(Class) calls,
which would then be repeated per tenant. But other than that, what specific
measurements have you taken to think that a Configuration is costly (per
tenant)? How
Of course, you can scope your fetchSize alteration to an individual
ResultQuery by calling ResultQuery.fetchSize(), as well.
On Wed, Jun 5, 2024 at 12:23 PM Lukas Eder wrote:
> Hi Ryan,
>
> You shouldn't modify the Settings object of your single application scoped
> DSLContext, be
Hi Ryan,
You shouldn't modify the Settings object of your single application scoped
DSLContext, because that's not a thread safe operation. Instead, access
DSLContext.configuration() and call Configuration.derive() (or
deriveSettings() for convenience) in order to create a locally scoped
On Sat, Jun 1, 2024 at 8:55 PM Dominik Hirt
wrote:
> private Boolean hasModifiedBy(Record dbRecord) {
>Boolean result = Boolean.FALSE;
>
>Method[] methods = dbRecord.getClass().getDeclaredMethods();
>for (Method method : methods) {
> if (method.getName().equals("getModifiedBy"))
On Fri, May 31, 2024 at 3:48 PM 'Bernd Huber' via jOOQ User Group <
jooq-user@googlegroups.com> wrote:
> how could jooq-migrations detect, when a changeset has changed.
> Other migration-frameworks would compare the SQL in the Changeset/File
> with the SQL in the "Protocol-Table" (in liquibase
Hello,
Assuming you cannot use triggers for some reason, one simple way to do this
is to:
- Intercept all INSERT queries with an ExecuteListener
- Use the experimental query object model (QOM) API to set
QOM.Insert::$columns and QOM.Insert::$values, if QOM.Insert::$into is the
right target table
Version 3.17.25 - May 30, 2024
This is a 3.17 patch release with minor improvements and bug fixes
Bug Fixes
-
#16654 - TableRecords should refresh() themselves for HANA dialect, when
any
On Wed, May 29, 2024 at 12:04 PM Giovanni Zotta <
giovanni.zo...@teampicnic.com> wrote:
> Thanks all for the replies, very useful! I think getting the IDs on the
> client and then using COPY makes sense, and sounds like the best
> alternative.
>
> The problem I have now is that I don't have an
Our loader API has multiple options to throttle insertions through jOOQ API:
https://www.jooq.org/doc/latest/manual/sql-execution/importing/importing-options/importing-option-throttling/
But the loader API doesn't support the RETURNING clause. I'm assuming
you're using an IDENTITY (or serial)
jOOQ cannot possibly detect what kind of change you did manually, and
respect that change. I'm not aware of any code generator that is able to
keep arbitrary changes in generated code.
IDEs can be configured to leave derived resources, such as generated code,
alone and not touch their contents.
You shouldn't modify generated sources!
I understand that line separators may be changed by version control, so you
could adapt the code generator to produce what you're using elsewhere:
Thanks for your message.
jOOQ doesn't modify (touch) files which don't have any changes in them.
On Tue, May 28, 2024 at 12:57 PM Muhammad Atif
wrote:
> This show hug change in PR review and hard to look after every bit of code.
I'm afraid, I don't know what this means
--
You received this
There has also been an idea in the past to allow for other relational
operators on arbitrary table expressions, such as Table.select() but it was
rejected because the time wasn't ripe for such an operator yet, at the time:
- https://github.com/jOOQ/jOOQ/issues/13066
For the record, I'll
Thanks a lot for your feedback, Bernd, greatly appreciated!
On Mon, May 20, 2024 at 1:08 PM 'Bernd Huber' via jOOQ User Group <
jooq-user@googlegroups.com> wrote:
> I even searched for a jOOQ sticker online to put on my work laptop, but
> thats something still missing :)
>
You get stickers if
On Mon, May 20, 2024 at 4:49 PM fabio trabattoni
wrote:
> Thank you for your thoughtful response, Lukas. I'd like to clarify a few
> points:
>
> I don't consider my idea revolutionary, nor do I aim to build the next big
> framework from it. It was a simple attempt to solve a small problem.
>
>
Hi Bernd,
Thanks for your message.
Indeed, there's a jOOQ-migrations draft module, which is currently on hold,
but not abandoned. The main reason for it being on hold is that there are a
lot of much simpler things to do in jOOQ itself before tackling such a huge
project like database migrations.
Thanks for your message.
For the record of others following this discussion, it's a follow-up to
this Stack Overflow question:
https://stackoverflow.com/q/78495895/521799
Fetch plans like these aren't a new idea. JPA does indeed already explore
such functionality via entity graphs. I've seen
Hi Kevin,
Thanks for your message. The method was introduced with jOOQ 3.18:
https://github.com/jOOQ/jOOQ/issues/13986
As you can see from the @Support annotation on the method, we don't support
it yet for SQLite:
Hi Alessandro,
Thanks a lot for your report. This is a funny edge case bug, which I've
created here:
https://github.com/jOOQ/jOOQ/issues/16662
The reason for this practice is documented in this earlier bug here:
https://github.com/jOOQ/jOOQ/issues/10007
javac has a size limit for string
Version 2.0.1 - May 7, 2024
This is a 2.0 patch release with minor improvements and bug fixes
Features and Improvements
-
- [#183] Add Match.attrNames(): Set
Bug Fixes
-
- [#188]
Thanks for your feedback.
I've created an issue to improve the warning message to include these hints:
https://github.com/jOOQ/jOOQ/issues/16656
On Tue, May 7, 2024 at 7:16 AM Petar Andreev wrote:
> Thanks Lukas, it works
>
> On Monday, May 6, 2024 at 2:32:22 PM UTC+2 Lukas Eder wrote
Hi Petar,
A DataType instance is available from your SEARCH.EXAMPLE.TYPE
column, for example. It might be available elsewhere, too. You can create
it as well manually in various ways, e.g.
SQLDataType.VARCHAR.asConvertedDataType(...).
I hope this helps,
Lukas
On Mon, May 6, 2024 at 2:29 PM
Hi Nico,
I think the error message explains it? You cannot have a scalar subquery
that produces more than 1 row:
https://www.jooq.org/doc/latest/manual/sql-building/column-expressions/scalar-subqueries/
Check your data. It appears that your union produces 2 rows instead of 1.
I hope this helps,
Version 3.17.24 - May 2, 2024
This is a 3.17 patch release with minor improvements and bug fixes
Bug Fixes
-
#16550 - Auto wrap Field arguments to a Routine's Object typed parameter in
Field
#16555
On Wed, May 1, 2024 at 12:54 PM Ahmed Ghanmi
wrote:
> We are concerned that we'd end up with recurring performance issues on PG
> due to the casts. As a starting point will we have to rewrite indexes to
> account for the casts?
>
I'm not sure what you mean by this. Bind values are cast by jOOQ,
Hi Ahmed,
The default MetaProvider uses JDBC DatabaseMetaData and doesn't cache
itself. You can implement your own MetaProvider, where you cache the
results e.g. using Meta.snapshot(), or you can use another implementation,
e.g. a DDL based one:
Hi Ahmed,
Casting is necessary a lot of times in PostgreSQL (much more than in
Oracle), so these automatic casts won't go away, nor is there a flag to
deactivate them.
1. There is not.
2. Meta lookups always helps, yes
Do you have any specific concerns related to casts? you said you wanted to
t; Hi Lukas,
>> Thanks again, You are alright.
>> Problem solved.
>>
>> Le lun. 29 mars 2021 à 12:26, Lukas Eder a écrit :
>>
>>> Hi Walid,
>>>
>>> - Whoever opens a JDBC Connection is responsible for closing it again
>>> - You
My suggestion is to generate your schema from the "base schema" in your dev
environment, for example, to get a CUSTOMER table. And then, for customer
13, configure a Configuration / Settings that rewrites all references to
CUSTOMER to CUSTOMER_DATA_13.
Obviously, you can rename tables on a
Hi Jason,
Unless you have complex, per-query naming logic for those tables (in case
of which Replacers would be a good approach), I think that your use-case is
still sufficiently covered by the runtime schema/table mapping feature?
It's a table valued function. You can use it in the FROM clause of your
query. How else would you want to use it?
On Friday, April 12, 2024, suman choudhary
wrote:
> Hi Lukas,
>
>
> My stored procedure is returning a SET OF TEXT, but when Jooq reads from
> the physical schema, it treats the
Version 3.17.23 - April 4, 2024
This is a 3.17 patch release with minor improvements and bug fixes
Features and Improvements
-
#16491 - Add DataType.isFloat()
Bug Fixes
-
you switch from JOOQ version 3.19.5 to 3.19.6 the generated code stops
> being a sourceSet, if you then switch back to 3.19.5 it becomes a sourceSet
> again
>
> [image: image.png]
>
> [image: image.png]
>
> My JOOQ plugin configuration is in the build.gradle.kts file
Hi Bernd,
Thanks for sharing all of this. Very interesting insight, also for future
jOOQ features.
On Thu, Mar 28, 2024 at 4:36 PM 'Bernd Huber' via jOOQ User Group <
jooq-user@googlegroups.com> wrote:
> Hello Lukas,
>
> yes, i would use them, but the jOOQ's records are representing the
>
lso:
https://www.jooq.org/doc/latest/manual/code-generation/codegen-gradle/
On Wed, Apr 3, 2024 at 11:40 AM Lukas Eder wrote:
> Hi Simone
>
> I'm assuming you installed the trial's jar file to your local Maven
> repository. Did you set up your gradle repositories as follows?
>
> build.gra
Hi Simone
I'm assuming you installed the trial's jar file to your local Maven
repository. Did you set up your gradle repositories as follows?
build.gradle.kts
repositories {
mavenLocal()
mavenCentral()
}
settings.gradle.kts
pluginManagement {
repositories {
What keeps you from just using jOOQ's records?
On Thu, Mar 28, 2024 at 11:53 AM 'Bernd Huber' via jOOQ User Group <
jooq-user@googlegroups.com> wrote:
> Hello guys,
>
> this is not directly jOOQ related, but maybe someone here has already had
> this problem, and has some input to share.
>
> I
The DefaultConfiguration::data map is a ConcurrentHashMap, so readers and
writers won't corrupt the Map when accessing it concurrently. But indeed,
the Map is shared if you share the Configuration. You can either use
tenant-specific Map keys (like "com.example.tenant-1", etc.) or maintain a
Hi Simone,
Thanks for your message. Yes, you should be able to reuse the same
generated schema on both RDBMS. The most common pitfalls are:
- Differing types (you're already looking into that)
- Differing identifier default case and case sensitivity (you can either
quote all identifiers in DDL
Hi Bernd,
On Mon, Mar 25, 2024 at 6:04 PM 'Bernd Huber' via jOOQ User Group <
jooq-user@googlegroups.com> wrote:
> Hello Lukas,
>
> the generic Map is indeed a good solution.
> I have changed my code accordingly, and the result looks better!
> I can use the default nested-transactions the way
On Mon, Mar 25, 2024 at 11:35 AM 'Bernd Huber' via jOOQ User Group <
jooq-user@googlegroups.com> wrote:
> Hello Lukas,
>
> thanks for following up.
>
> exactly like you said, i wrote the own utility because i want to pass the
> following data from the Manager/Services-Layer into the DAO-Layer for
Hi Bernd,
The try-with-resources approach will not work unless you're OK with the
explicit commit. I've explored this as well in the past:
https://stackoverflow.com/q/21353508/521799
But you don't really need any of that, as jOOQ's DSLContext.transaction()
API already supports this nesting style
On Fri, Mar 22, 2024 at 12:16 PM Marcel Overdijk
wrote:
> Thanks for detailed feedback Luka, I really appreciate it.
>
> I think https://github.com/jOOQ/jOOQ/issues/16498 makes sense,
> but also MariaDB supports the { d '*str*' } expression (as expected as
> it is a fork), so even in my case
Marcel,
Yes I know it’s a challenge to try to create “ANSI SQL” files.
>
I've just thought of a problem you will inevitably run into with your
approach: jOOQ does not give you any guarantee of "ANSI SQL." If you pick
any dialect (e.g. PostgreSQL), it will generate a "reasonable" SQL query or
Thanks for your message.
The logic to prevent quoting in SQLite is very old. I don't recall the
exact reason, but I believe that SQLite's parser had a lot of trouble with
quoted identifiers in some contexts - so the solution was to simply avoid
quoting, except for identifiers that conflict with
I've split the issue in two. The NULLIF(?, '') solution is available from
the next 3.20.0-SNAPSHOT builds:
https://github.com/jOOQ/jOOQ/issues/16483
On Tue, Mar 19, 2024 at 3:16 PM Lukas Eder wrote:
> For the time being, as a workaround, you could use the experimental model
> API repla
just about execution, you could implement a
JDBC proxy that overrides the behaviour of PreparedStatement.setString()
On Tue, Mar 19, 2024 at 3:14 PM Lukas Eder wrote:
> I see, we currently don't do anything specific here. I've created a
> feature request to add some flags for this purpose:
>
I see, we currently don't do anything specific here. I've created a feature
request to add some flags for this purpose:
https://github.com/jOOQ/jOOQ/issues/16478
I can see two types of flags:
1. A flag governing how we interact with JDBC. This works only when
executing the query with jOOQ
2. A
EPLACE FUNCTION get_employee_names() RETURNS TABLE (name text)
> AS $$ BEGIN RETURN QUERY SELECT name FROM employees; END; $$ LANGUAGE
> plpgsql;
>
> Regards,
> Suman Choudhary
> On Tue, 19 Mar 2024 at 4:19 PM, Lukas Eder wrote:
>
>> Thanks for your message.
>>
>>
Thanks for your message.
Can you provide an example of what you're trying to do, please
On Tue, Mar 19, 2024 at 11:47 AM suman choudhary <
choudharysuman...@gmail.com> wrote:
> Hi Lukas,
>
> Does JOOQ support custom functions that returns List?
>
> Thanks and Regards,
> Suman Choudhary
>
> --
On Tue, Mar 19, 2024 at 9:36 AM Marcel Overdijk
wrote:
> Thanks Lukas,
>
> I created https://github.com/jOOQ/jOOQ/issues/16470 for this.
>
> > We can do a topological sort.
>
> That sounds hopeful! Not sure how to do it, so if there is anything you
> share that would be great.
>
Well, if there
On Mon, Mar 18, 2024 at 10:26 PM Marcel Overdijk
wrote:
> Related to generating the schema ddl I found there is the dsl.ddl(schema)
> method of jooq.
Great that you've found it! :)
> I noticed it generates the ddl in the order:
> create table country ...
> create index ...
> alter table
Hi Marcel,
On Mon, Mar 18, 2024 at 3:38 PM Marcel Overdijk
wrote:
> Hi Lukas, and thanks for your reply. This helps a lot.
>
> I used jOOQ In the past with code generation and I understand the benefits
> especially in terms of type information and type safety.
>
Sure, I knew you were aware of
Hi Ahmed,
Thank you for your message. Can you please show an example with details
about what you mean, specifically?
Best regards,
Lukas
On Mon, Mar 18, 2024 at 3:54 PM Ahmed Ghanmi
wrote:
> Hello Lukas,
>
> In our Oracle->PG migration, we are using JOOQ's ParsingConnection to
> translate
You can specify the Settings.parseUnknownFunctions flag to tell jOOQ's
parser to ignore unknown scalar functions
On Mon, Mar 18, 2024 at 2:07 PM deepankar gupta <
deepankargupta1...@gmail.com> wrote:
> Hi Lukas,
>
> Does jooq parser support other than user-defined table valued functions
> like
Hi Deepankar,
Thank you for your message. Our parser doesn't support user-defined table
valued functions yet, see:
https://github.com/jOOQ/jOOQ/issues/16200
But you can implement your own ParseListener to intercept the parsing of
Table expression and implement your own behaviour easily:
Hi Marcel,
The SQL DSL can't do that for you, but you can turn any POJO into a Record
using Record.from() or DSLContext.newRecord(...). You can then use
.insertInto(table).set(record). There's a RecordUnmapper SPI that governs
how to "unmap" POJOs into records, with a DefaultRecordUnmapper
It does seem like something worth reporting to IntelliJ, though I recall
how slippery the implementation of a lazy configuration was, so it won't
hurt to investigate if the 3.19.6 plugin now does something "stupid." The
current logic to register the code generation output directory with the
source
only within the IDE that I'm
> seeing the issues,
>
> I've tried invalidating IDEA's caches but still have the same issue.
>
>
> Kevin
>
> On Fri, Mar 8, 2024 at 5:24 PM Lukas Eder wrote:
>
>> 3.19.6 has been released and the gradle plugin configuration should now
3.19.6 has been released and the gradle plugin configuration should now be
lazy.
Let me know if this fixes the remaining problems for you.
On Friday, March 1, 2024, Lukas Eder wrote:
> Task configuration is now lazy with the next nightly builds of 3.20.0 and
> 3.19.6:
> https://github
Hi Alessandro
Thank you for your message. For historic reasons, Field.in(Collection)
isn't type safe. This is because of erasure, we can't have both
Collection and Collection> arguments. This
is why the Java compiler didn't tell you about your mistake. The IN
predicate already accepts a
Version 3.17.22 - March 8, 2024
This is a 3.17 patch release with minor improvements and bug fixes
Bug Fixes
-
#16350 - Parser fails with StringIndexOutOfBoundsException when
encountering invalid
Hi Guarav,
Thank you for your message. Our parser can currently only parse simple
procedural logic, see:
- https://www.jooq.org/doc/latest/manual/sql-building/procedural-statements/
-
https://www.jooq.org/doc/latest/manual/sql-building/sql-parser/sql-parser-grammar/
It is unlikely that you'll
everyone for the help!
>
> On Fri, 23 Feb 2024, 10:38 Lukas Eder, wrote:
>
>> Hi Pasha,
>>
>> Yes, see this issue for lazy configuration evaluation:
>> https://github.com/jOOQ/jOOQ/issues/16188
>>
>> On Fri, Feb 23, 2024 at 8:24 AM Pasha Finkelshtei
On Thu, Feb 29, 2024 at 8:30 PM Khun Yee Fung
wrote:
> Due to company policy, unfortunately, I can't simply just upload the DDL
> of the schema that caused the issues. So, I tried to recreate the
> relationships to reproduce the errors. I tried up to 30 tables, generated
> in various ways to try
Thanks for the follow up details. That seems to be another bug. Can you
please post a complete reproducer including:
- The CREATE TABLE for all relevant tables
- The complete code generation configuration
On github, we usually ask users to provide a minimal, complete, verifiable
reproducer based
Hello,
Thanks for your report. This isn't a known issue yet. I've created a bug to
track this:
https://github.com/jOOQ/jOOQ/issues/16379
What other errors are you getting if you don't generate the indexes? There
only few reasons why you need the indexes in generated code, so the
simplest
Version 3.17.21 - February 27, 2024
This is a 3.17 patch release with minor improvements and bug fixes
Bug Fixes
-
#16322 - Wrong SQL generated when nesting predicates on subqueries
projecting
jOOQ doesn't implement indexing. I really suggest learning about those
first. You'll see immediately why jOOQ can't offer help with indexing your
data here (other than creating the CREATE INDEX statements, of course, but
it doesn't matter if you create them via jOOQ or directly in SQL).
If you're
Yes
On Tue, Feb 27, 2024 at 1:33 AM Jason Bennett wrote:
> Appreciate all of the help you provide, Lucas.
>
> I have an Ltree column, which I've generated using the extension jar, so
> it's a proper Ltree type in jOOQ. I would like to run an lquery against
> this column, but jOOQ doesn't seem
Josh,
I mean indexes on your database columns. Do you have an index on relevant
columns of your table? If you don't know about indexing in SQL, I highly
recommend this book (use the "jooq" discount code for 10% off, though it's
only 10 EUR for the PDF version):
Hi Josh,
I'm not aware of any such significant performance penalties within jOOQ
itself (although, in case you're using R2DBC, there may still be issues
that I'm unaware of). There is also little risk of running into a
concurrency issue within jOOQ. The only place I recall where there's some
sort
Hi Pasha,
Yes, see this issue for lazy configuration evaluation:
https://github.com/jOOQ/jOOQ/issues/16188
On Fri, Feb 23, 2024 at 8:24 AM Pasha Finkelshtein <
pavel.finkelsht...@gmail.com> wrote:
> Hi @Lukas,
>
> After some experimenting, I think that I hit an issue with the jOOQ Gradle
>
Well, what did you try?
On Thu, Feb 22, 2024 at 10:19 AM Pasha Finkelshtein <
pavel.finkelsht...@gmail.com> wrote:
> This obviously SHOULD work, but it doesn't. And I was hoping to get a
> concrete example to understand what I'm doing wrong.
>
> It seems to me that test containers just don't
:
> I tried, no luck yet :)
>
> But I believe it's just something nobody did - launch a container for
> build, not for tests.
> Also, LiquibaseDatabase won't work for me, because I use `CALL` in my
> migrations, which creates a lot of entities in the DB...
>
> On Thu, 22 Feb
1 - 100 of 4296 matches
Mail list logo
