Hi Lukas, thank you, that's amazing I didn't realize before, that this feature is also implementable. For my initial use case JdbcDatabase and it's descendands is far enough - users of my app will pass JDBC connection params, and the app will display database metadata and allow executing standardized SQL processed by JOOQ Parser to get data for reports.
But this brings to my head another question about JOOQ licensing ... I know that in standard case, model generation (from metadata) and writing parseable SQL is done by developer (therefore I think per developer license is reasonable here). But in my case this JOOQ functionality will be used by application users and not developers, albeit without directly using JOOQ java API. My app takes this case into the extreme, because my Jupiter Notebook Kernel will also allow execute standard java code (besides SQL execution) to further process SQL results (java code execution will be definitely available *without *JOOQ libraries in classpath). Therefore the essential question is, if the license cost will be counted per developer or per app user for my app. Possibility to create "universal report" (by using standard, translatable SQL) executable on any supported database with the same schema is one of the amazing features, which are possible to do with JOOQ. There are a lot of applications, which support multiple databases (e.g. like JIRA internally using Hibernate) and the possibility for company to create universal report executable on any db engine is one of the big "sellpoints" of my proposal. There are also other nice features possible, like static validation of existing SQL queries (reports) when schema is upgraded etc. But if it makes any significant change in JOOQ licensing for me I am ready to postpone this feature for now and not to present it as planned for first version (I am planning to start Kickstarter project for it), and use JOOQ only for database metadata analysis tool and native SQL execution wrapper. thanks for response Marek pi 26. 7. 2019 o 15:36 Lukas Eder <[email protected]> napísal(a): > Hi Marek, > > Notice, we've decided to include a minor feature in the upcoming version > 3.12, which could be helpful to you: > https://github.com/jOOQ/jOOQ/issues/8986, in which we will simulate DDL > using an in-memory H2 database, which we can reverse engineer again to > derive all schema meta information. This will be useful to your parser > usage, as a lot of the jOOQ features depend on jOOQ knowing schema meta > information that is specified by DDL (probably), in your case. > > I hope this helps, > Lukas > > On Thursday, July 18, 2019 at 3:48:13 PM UTC+2, marekgregor wrote: >> >> Hi Lukas, >> >> that is definitely great news, so I am sure JOOQ will be the right choice >> for this functionality. Now I will try to evaluate JOOQ in the prototype >> version. >> Thanks for response and links. >> >> Marek >> >> Dňa štvrtok, 18. júla 2019 15:16:30 UTC+2 Lukas Eder napísal(-a): >>> >>> Hi Marek, >>> >>> Thank you very much for your interest in using jOOQ's parser for your >>> product. What you're planning to do sounds exactly like what we want to be >>> able to do, and offer as a library, with the parser / translator. >>> >>> However, there is still much work to do on our side. In order to be able >>> to associate parser artefacts, such as a mapping between the position in an >>> input string and a QueryPart, we'll have to re-design our QueryPart >>> internals and make them a public API. This will be a priority for the next >>> few jOOQ releases, but we're not quite there yet. Right now, you would have >>> to look into jOOQ's internals (possibly open them up using reflection) to >>> get access to this kind of information. >>> >>> Do note that there's a related discussion on GitHub where Scott McKinney >>> plans to use jOOQ as a SQL parser for Manifold: >>> https://github.com/jOOQ/jOOQ/issues/8720 >>> >>> If you're interested in continuing your jOOQ evaluation, we'd be very >>> keen on learning what kinds of requirements you may have from a future jOOQ. >>> >>> Best Regards, >>> Lukas >>> >>> On Wed, Jul 17, 2019 at 2:36 PM marekgregor <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> I am seriously considering implementation of Jupyter Notebook Kernel >>>> for SQL (+Java) language utilizing JOOQ. >>>> >>>> The Kernel will be capable to: >>>> - simultaneously connect to various databases for multiple users >>>> utilizing connection pooling, >>>> - provide database metadata to client (tables, columns, foreign keys, >>>> views, stored procs,...) utilizing JOOQ implementation >>>> <https://www.jooq.org/doc/3.11/manual/code-generation/codegen-advanced/codegen-config-database/codegen-database-name/> >>>> , >>>> - execute database native SQL or standardized SQL translated to native >>>> SQL by JOOQ parser functionality >>>> <https://www.jooq.org/doc/3.11/manual/sql-building/sql-parser/sql-parser-api/> >>>> and >>>> return it's results to client >>>> >>>> Kernel could also support autocomplete and introspection for SQL code >>>> written in editor on client side of Jupyter Notebook. The API >>>> implemented by kernel >>>> <https://jupyter-client.readthedocs.io/en/stable/messaging.html#completion> >>>> for >>>> autocomplete is pretty simple: client sends code (SQL) string and cursor >>>> position, kernel response contains list of autocomplete recommendation >>>> strings etc. >>>> >>>> I am curious if it is possible to use JOOQ for parsing SQL to >>>> QueryPart(s), identify which QueryPart >>>> <https://www.jooq.org/javadoc/3.11.x/org/jooq/QueryPart.html>corresponds >>>> to defined SQL string cursor position and return corresponding autocomplete >>>> strings (e.g. with names of available tables in FROM clause, or names of >>>> columns in SELECT clause). I don't know if it is suitable to use JOOQ for >>>> this task and how. >>>> >>>> thanks for response >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jooq-user/eab246d8-2947-4686-9d29-1be0e1ca6182%40googlegroups.com >>>> <https://groups.google.com/d/msgid/jooq-user/eab246d8-2947-4686-9d29-1be0e1ca6182%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "jOOQ User Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jooq-user/2wPGf6uB5fI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jooq-user/6818c855-1a51-47be-9af8-73934b3bc407%40googlegroups.com > <https://groups.google.com/d/msgid/jooq-user/6818c855-1a51-47be-9af8-73934b3bc407%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CACtQWuQT%2BNueHTD3FOfiSD3TWCB2zkRX3iAHiEXXqwfWahHkbw%40mail.gmail.com.
