Digest for jooq-user@googlegroups.com - 6 updates in 3 topics

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

Digest for jooq-user@googlegroups.com - 6 updates in 3 topics

http://groups.google.com/group/jooq-user/topics mailing list
Marek Gregor <[hidden email]>: Sep 09 10:15AM +0200

Hello Lukas,
 
thanks a lot for response, I am sorry, I have not noticed the obvious bug
in my DDL, the reflection warnings deceived me.
I have not realized that parsing unqualified column names is not so
straightforward to implement, I think existing state - using qualified
names is perfectly fine for use.
 
Feature of parsing with meta lookups (.withParseWithMetaLookups(
THROW_ON_FAILURE)) is perfect for validation of queries without even
running them, this I think will be killer feature for any reporting tool
;). In DslContext.meta() I miss only one thing - possibility to list and
run stored procedures (org.jooq.Routine) in some dynamic way without static
generation. But this could be also implemented by me when needed, by
reverse engineering code of org.jooq.codegen.JavaGenerator#generateRoutines
in a way to support dynamic calling of routines without code generation ...
 
Thank you once more time for marvelous support.
 
Marek
 
Lukas Eder <[hidden email]>: Sep 09 11:16AM +0200

Hi Marek,
 
 
> Hello Lukas,
 
> thanks a lot for response, I am sorry, I have not noticed the obvious bug
> in my DDL, the reflection warnings deceived me.
 
No worries at all! What jOOQ distribution did you get those reflection
warnings with? There's a known issue in the jOOQ Open Source Edition where
those warnings persist, but they should have been fixed in the commercial
JDK 11 distributions...
 
 
> I have not realized that parsing unqualified column names is not so
> straightforward to implement, I think existing state - using qualified
> names is perfectly fine for use.
 
Yes, unfortunately, but rest assured, this is a high priority for us.
 
 
> generation. But this could be also implemented by me when needed, by
> reverse engineering code of org.jooq.codegen.JavaGenerator#generateRoutines
> in a way to support dynamic calling of routines without code generation ...
 
That is on our roadmap. We might need to implement a few prerequisites
first, including a routine meta model (which is currently mixed with the
actual routine call):
https://github.com/jOOQ/jOOQ/issues/8748
 
Definitely something we'd like to add soon as well, as we're also going to
support parsing routine DDL statements, such as CREATE FUNCTION and CREATE
PROCEDURE.
 
Thanks,
Lukas
Marek Gregor <[hidden email]>: Sep 09 11:42AM +0200

Thanks for clarification, I have tried <groupId>org.jooq</groupId>,<
artifactId>jooq</artifactId>,<version>3.12.0</version>.
 
 
 
Lukas Eder <[hidden email]>: Sep 09 12:01PM +0200

I see. Yes, that version still suffers from
https://github.com/jOOQ/jOOQ/issues/9157. I'm hoping to fix this for one of
the next patch releases.
 
"Tim B├╝the" <[hidden email]>: Sep 09 02:39AM -0700

Hi,
 
I originally asked my question here:
https://stackoverflow.com/questions/57796087/
<https://stackoverflow.com/questions/57796087/how-to-use-jooqs-parser-to-extract-table-names-from-sql-statements?noredirect=1#comment102048796_57796087>
 
I'm trying to parse SQL statements and extract table names using JOOQ's
parser <https://www.jooq.org/doc/3.11/manual/sql-building/sql-parser/>. The
problem is, the Query and SelectQuery don't seem to provide a public getter
for the parsed table list.
 
val parser = DSL.using(SQLDialect.POSTGRES_10).parser()
 
val queries = parser.parse("SELECT foo, bar FROM mytable WHERE id = 1;")
 
for (query in queries) {
 
when (query) {
 
is SelectQuery<*> -> println(query.fields().map { it.name }) // can find the fields, but not the tables
 
else -> println(query)
 
}
 
}
 
I could indeed help myself accessing the private field using reflection,
but I wonder if there is an easier way:
 
val field = query.javaClass.getDeclaredField("from")
 
field.isAccessible = true
 
println(field.get(query))
 
And of course, this should also work for other statements (e.g. Insert,
update, delete).
 
 
Lukas encouraged me to come here and elaborate on the use case. So here it
goes:
I have this central database which is accessed by a bunch of different
applications. They all use the same credentials, which is the user account
owning all tables with full permissions to everything. I want to introduce
dedicated logins and restrict the permissions to what is currently used.
 
To find which objects are used by a given consumer I want to do the
following:
 
- create dedicated accounts with full permissions for each consumer
- activate statistics
- query pg_stat_statements to get the executed statements for a given
username
- use JOOQ to extract table names and set permissions accordingly
 
 
If I don't find something that parses SQL reliably, I going to retrieve the
list of existing tables and simple check if I find a given table name in
the queries obtained from pg_stat_statements, which might be good enough
actually.
If you could think of a simpler approach I'm would be happy to hear your
thoughts on it.
 
regards,
Tim
Lukas Eder <[hidden email]>: Sep 09 09:36AM +0200

Hi Chris,
 
Thank you very much for your message.
 
jOOQ has not been modularised yet, as jOOQ's optional dependencies have
made this difficult in the past (e.g. H2, Hibernate, JAXB, checker
framework, depending on whether you're using extensions). We'll try again
in the future, but this hasn't been a priority for us, since also IDEs have
caused a lot of trouble when maintaining modularised projects.
 
Like any non-modularised library, you can use jOOQ on the classpath, or as
part of the unnamed module. I'm not aware of anything specific to jOOQ in
that regard.
 
I hope this helps,
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].