How to prefix all generated java class names?

[Peter Ertl]

Is there a simple way to add a prefix to all generated classes, e.g. a capital 'J' so table "application" will be mapped to "JApplication.java"?

[Lukas Eder]

Hi Peter,

> Is there a simple way to add a prefix to all generated classes, e.g. a
> capital 'J' so table "application" will be mapped to "JApplication.java"?

The GeneratorStrategy is documented in the manual:
http://www.jooq.org/doc/2.6/manual/code-generation/codegen-advanced/

It shows how to inject a custom naming strategy in order to achieve
what you're trying to do

[Peter Ertl]

Thanks Lukas,

works like a charm (didn't expect anything else :-)

Altering the naming in case of using the maven plugin is a little cumbersome since you need to define the custom naming scheme in an additional, external dependency / module. Having the naming scheme in the same module as the generator plugin will not work since the generator will execute _before_ maven starts compiling the java files.

I think the usecase of adding a prefix to the class is name is so useful that I suggest adding something like 'PrefixNamingGenerator' in jooq-util. Especially when running side-by-side with JPA or Hibernate since entities usually have the same names as the jOOQ classes which is very inconvenient.This would be similar to querydsl settings 'querydsl.prefix' (http://www.querydsl.com/static/querydsl/2.2.0/reference/html/ch03s02.html) which by default uses prefix 'Q'.

Marking all jOOQ classes with an capital 'J' would be cool for me and I could easily lookup jOOQ classes by typing 'J' in the type search of IDEA or eclipse :-)

Cheers

Peter

[Peter Ertl]

little typo: I did not mean 'jooq-util' but 'jooq-codegen'

[Lukas Eder]

Hi Peter,

> Altering the naming in case of using the maven plugin is a little cumbersome
> since you need to define the custom naming scheme in an additional, external
> dependency / module. Having the naming scheme in the same module as the
> generator plugin will not work since the generator will execute _before_
> maven starts compiling the java files.

I'm aware of this issue. I had asked a Stack Overflow question to get
some input on the matter, some time ago:
http://stackoverflow.com/q/10322155/521799

However, that's how Maven works. I guess, one can get used to it...

> I think the usecase of adding a prefix to the class is name is so useful
> that I suggest adding something like 'PrefixNamingGenerator' in jooq-util.
> Especially when running side-by-side with JPA or Hibernate since entities
> usually have the same names as the jOOQ classes which is very
> inconvenient.This would be similar to querydsl settings 'querydsl.prefix'
> (http://www.querydsl.com/static/querydsl/2.2.0/reference/html/ch03s02.html)
> which by default uses prefix 'Q'.

Yes, this has been requested before:
https://github.com/jOOQ/jOOQ/issues/408
https://github.com/jOOQ/jOOQ/issues/830
https://github.com/jOOQ/jOOQ/issues/1126
https://github.com/jOOQ/jOOQ/issues/1171
https://groups.google.com/forum/#!msg/jooq-user/o_eN0g6XjyM/EGFHy6DMpy4J

As you can see in #408 and #1126, users tend not to stop at wanting
prefixes. At some point, they will want suffixes, and then both, and
then CamelCasing vs. UNDERSCORE_NOTATION. And then, they will want
different prefixes for tables and for records, but no prefixes for
table references... :-)

NamingStrategy already covers all that with no additional maintenance
effort for me :-) At some point, I will implement #1171, which is
probably the most generic way to handle this seemingly simple feature
request of adding prefixes (and then suffixes and then renaming and
then...). In fact, it is an XML-based way to configure a Java
NamingStrategy implementation.

> Marking all jOOQ classes with an capital 'J' would be cool for me and I
> could easily lookup jOOQ classes by typing 'J' in the type search of IDEA or
> eclipse :-)

Yes, I can see the usefulness of that.

[Peter Ertl]

I guess if you add all the _simple_ features in a "SimpleNamingStrategy" (having "Simple" in the name will be important *lol* ) it will be obvious to people that it will cover only the most basic use cases and you will not raise a maintenance nightmare :-)

This should satisfy 98% of all jOOQ users with very little work required.

What you think?

[Lukas Eder]

> I guess if you add all the _simple_ features in a "SimpleNamingStrategy"
> (having "Simple" in the name will be important *lol* ) it will be obvious to
> people that it will cover only the most basic use cases and you will not
> raise a maintenance nightmare :-)
>
> This should satisfy 98% of all jOOQ users with very little work required.
>
> What you think?

Feel free to contribute a "SimpleNamingStrategy" :-) (including a
simple JAXB configuration that works both with the standalone code
generator and with Maven)

[Peter Ertl]

Fair enough for me :-)

[Lukas Eder]

> Fair enough for me :-)

Was that a "yes, let me implement that"? Or a "yes, I think the
current solution is good enough for me"? ;-)

[Peter Ertl]

Thay was a "I will try to provide a solution once I got enough insight into the jOOQ source I just checked out" :-)

[Lukas Eder]

Thay was a "I will try to provide a solution once I got enough insight into the jOOQ source I just checked out" :-)

Wonderful! Do note that one of jOOQ 3.0's goal is to provide better extensibility of the code generator to users. Any ideas, suggestions, contributions in that area are very welcome as well. Maybe, you'll discover something along the way

[Stéphane Cl]

I think it is a real problem. My existing table names are spelled in some way they just can't look nice when translated to java code.
I spent a lot of time creating my own generator strategy. There is little documentation and because I was in a hurry and could not easily figure out the actual logic the *println way*, I ended up calling super and overwriting the corresponding jooq generated name.
You said you are are planning to rewrite code generation to turn it into a 2 steps process, but are you going to offer a nicer way to customize Java class and property names on a per table basis?

Something like an XML definition file would be nice, don't you think so?
Best

[Lukas Eder]

> You said you are are planning to rewrite code generation to turn it into a 2 steps process, but are you going to offer a nicer way to customize Java class and property names on a per table basis?

You can already achieve this today, programmatically. When I find some time, I shall better document this feature. I'll give you an example for your use case within the next three weeks (currently not at home)

> Something like an XML definition file would be nice, don't you think so?

Yes, as covered by a recent feature request mentioned in this thread

[Stéphane Cl]

On Tuesday, 15 January 2013 03:17:22 UTC+1, Lukas Eder wrote:

You can already achieve this today, programmatically. When I find some time, I shall better document this feature. I'll give you an example for your use case within the next three weeks (currently not at home)

No, please do not spend too much time on this, it's fine the way I am doing it now. When appropriate, I'll switch to v3 and forget about my quick and dirty code.

[Lukas Eder]

> No, please do not spend too much time on this, it's fine the way I am doing
> it now. When appropriate, I'll switch to v3 and forget about my quick and
> dirty code.

That's good for you. But the amount of questions on this user group
related to that topic indicate that there aren't enough examples /
documentation in that section

Cheers
Lukas

[Peter Ertl]

Hi Lukas,

while not forgetting from my previous posts that a customizable strategy would be the ultimate(tm) solution I would still vote for additionally adding a simple out-of-the-box naming strategy (explained below) into jooq-codegen. 

Let me explain the reason why:

- consider you use maven

- also consider that you mix jOOQ with something like *brrr* hibernate / eclipselink / [any orm]

-> chances are very, very high that the class names of the entity classes (e.g. Customer.java -> mapped to @Table "customer") will clash with the jOOQ generated class 'Customer' when using the default strategy. This is very(!) annoying and in order to avoid this you need a precompiled and maven repository deployed module dependency with a custom naming strategy.

This is required since compilation is not available in the "generate-sources" lifecycle of maven.

We currently use querydsl which prefixes all classes with 'Q'. We find that quite pleasing since we can easily find all generated classes in the type viewer of the IDE and practically no name clashes happen. Having a prefix is simple but effective.

So I would suggest to bundle a very simple naming strategy in jooq-codegen which would required very little space and maintenance but could probably make like 95% of all people with name clashes happy. There will still be people whining ("i want another prefix", "why not a suffix?" and such) but still a high percentage of people would just appreciate not having this darn name clashes. And then you can still have custom naming strategy.

I think avoiding name clashes overrules personal taste.

This would also make migration / integration of jOOQ into s$$t like hibernate / orm much sexier and in the end make adaption of jOOQ easier :-)

-----------------------

please add me to 'jooq-codegen' :-)

-----------------------

package org.jooq.util;

/**

 * variant of the default naming strategy {@DefaultGeneratorStrategy} adding

 * the prefix 'J' to generated class names (e.g. to avoid name clashes

 * with existing JPA entities and such)

 */

public class JPrefixGeneratorStrategy extends DefaultGeneratorStrategy {

@Override

public String getJavaClassName(final Definition definition, final Mode mode) {

return 'J' + super.getJavaClassName(definition, mode);

}

}

-----------------------------

enabling it would be a simple matter of adding

   <name>org.jooq.util.JPrefixGeneratorStrategy</name>

to pom.xml.

this class means practically zero maintenance effort but great relief for maven / hibernate users...

Best regards

Peter

[Lukas Eder]

And "J" would be for jOOQ? :-)

The message has been well received. I understand the usefulness of a
prefix generating strategy. I'm also aware of QueryDSL's adding a "Q"
to some of its generated types (I'm curious about other jOOQ <->
QueryDSL comparisons, should you like to share them on this list...)

I'll think about your "fix". I still prefer a generic solution, but I
can see how yours eases some pain, immediately.

Cheers
Lukas

2013/3/28 Peter Ertl <pete...@googlemail.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.
>
>

[Durchholz, Joachim]

Please forgive me if I'm rehashing something already considered, I just noticed this one and didn't see previous messages.

> - consider you use maven
> - also consider that you mix jOOQ with something like
> *brrr* hibernate / eclipselink / [any orm]
>
> -> chances are very, very high that the class names of
> the entity classes (e.g. Customer.java -> mapped to
> @Table "customer") will clash with the jOOQ generated
> class 'Customer' when using the default strategy.

Sure, but you could always generate the classes into separate packages.
You may hit occasional issues with needing full qualification.
The "Open Type" dialog in Eclipse isn't really a problem, you can type something like *pac*.Cu and you'll get classes with names like com.packaging.Customer.

Not sure how this would interact with your Maven woes. I couldn't connect your problems to the situation you described (I probably missed something).
The repository manager mention stuck out; my recent experience with Maven indicates that sooner or later, you'll be forced to use a repository manager anyway. I'm not sure that Jooq should accommodate merely postponing something that you'll have to do anyway.
(I tried Maven recently, in the end decided it's too rigid to be adapted to the workflow and migrated to Gradle. Gradle came with its own set of road bumps, but in the end, it worked out okay.)

Just my 2c.

Regards,
Jo

[Peter Ertl]

> You may hit occasional issues with needing full qualification. 

unfortunately it's not occasional at all... think about having a CustomerDaoImpl where hibernate sits next to jOOQ. Having entity names clash with jOOQ names would not be the exception but the norm. You would have lots of explicit imports in the code:

[[some set up example]]

public class CustomerDaoImpl implements CustomerDao {

  @Inject

  private Session hibernateSession;

  @Inject

  private Executor jooqExecutor;

  // ...

  public void doHibernateAndJooqStuff() {

     // first do some moderate cool hibernate stuff

     Customer entity = new Customer(...);

     // flush and clear session to avoid side effects to the loaded entities 

     // and prepare for some huge data operation without all the bloat

     session.flush();

     session.clear();

     // now do some extremely cool jOOQ stuff

     org.mycorp.coolproduct.service.api.model.jooq.generated.Customer customer = factory.select(...). /* ... */;

     // ^ YUK ugly shit we have in here

     // even uglier (will force line break on most screens)

     org.mycorp.coolproduct.service.api.model.jooq.generated.Customer customerReference = org.mycorp.coolproduct.service.api.model.jooq.generated.Customer.CUSTOMER;

   // do something with the reference

  }

}

I know some people (including me) that would consider this amount of explicit imports a no-go

> my recent experience with Maven indicates that sooner or later, you'll be forced to use a repository manager anyway. 

true. but we should not force people, when they consider switching from e.g. hibernate to jOOQ (which is *good*), to first setup a nexus repo in the company, convince the security team (optional), then install some tiny one-liner-payload naming strategy using a separate project, run "mvn deploy" with the proper account --> just to show off to the team how great the migration to jOOQ would be :-)

^ hope you get the idea

Cheers

Peter

P.S.: The 'J' was meant to be a prefix for 'jOOQ', right!

[Peter Ertl]

> I'll think about your "fix". I still prefer a generic solution, but I can see how yours eases some pain, immediately. 

I would not consider it a 'fix' but a pragmatic solution for quite a common usecase.

The usecase would be even more common when this entry-level obstacle ("name clash") would be easier to solve.

Also it would not stand against a generic solution but be an option.

Cheers

Peter :-)

[Lukas Eder]

2013/3/28 Peter Ertl <pete...@googlemail.com>:

>> I'll think about your "fix". I still prefer a generic solution, but I can
>> see how yours eases some pain, immediately.
>
> I would not consider it a 'fix' but a pragmatic solution for quite a common
> usecase.
>
> The usecase would be even more common when this entry-level obstacle ("name
> clash") would be easier to solve.

I agree with the majority of opinions on this user group, that an easy
way to add prefixes will be well-received. Using packages for the
distinction of the same object generated from various generators
(jOOQ's, Hibernate's, etc.) is insufficient, as only one of the
various copies can be imported at a time. Unfortunately, Java doesn't
have any local imports like Scala, or aliased imports like Scala or
Ceylon.

> Also it would not stand against a generic solution but be an option.

Precisely.

[Durchholz, Joachim]

You really mix Hibernate and JDBC (or Jooq) stuff within the same unit of work?
This didn't work too well for us; it's all too easy to have cross-pollution between Hibernate and JDBC data (mostly caching problems, but sometimes issues with JDBC data sent to helper functions that invoke Hibernate).

I have mixed feelings about your use case; I can see that it is desired, but I'd rather push people towards completing the migration, and having the ugliness of full qualification in the code helps with that.

>> my recent experience with Maven indicates that
>> sooner or later, you'll be forced to use a
>> repository manager anyway.
>
> true. but we should not force people, when they
> consider switching from e.g. hibernate to jOOQ
> (which is *good*), to first setup a nexus repo
> in the company,

You should already be using Maven because you have Hibernate.
Or at least something that uses Maven repositories.
Either way, importing Jooq should be just as easy or complicated as importing Hibernate.

> convince the security team (optional),

That should be easy. It's essentially just part of your set of build tools.

> then install some tiny one-liner-payload naming
> strategy using a separate project, run "mvn deploy"
> with the proper account --> just to show off to the
> team how great the migration to jOOQ would be :-)

That's the "Maven way": if something doesn't fit into its (rather narrow) definition of build lifecycle, fragment the project into mini projects that each deploy to the repository.

If you don't want to go that route, Maven is not the right tool for your situation (I got that straight from the horse's mouth when I asked about exactly that issue on the maven-users lists).
I switched my freetime project to Gradle and found that accessing Maven repositories from there was entirely painless. Maven Central also lists Buildr and Ivy as alternatives for building Java projects (plus Groovy Grape, Grails, and Scala SBT - funny how build tools have become so language-centric nowadays).
Our conversion to Gradle isn't complete yet, but we did find that it has zero issues with including a binary jar in a build. No need for an extra project, no need for a repository (we're keeping the Maven Repository Manager we set up as a cache, but it's inessential to the build process now).

[Peter Ertl]

Hi Joachim,

> You really mix Hibernate and JDBC (or Jooq) stuff within the same unit of work? 

> This didn't work too well for us; it's all too easy to have cross-pollution between Hibernate

> and JDBC data (mostly caching problems, but sometimes issues with JDBC data sent to helper

> functions that invoke Hibernate).

It does not work well unless you know the rules. We know these rules can be crazy, that why we basically like the SQL way better and try to get there (going the jOOQ path).

> I have mixed feelings about your use case; I can see that it is desired, but I'd rather push people towards completing the migration...

Doing a full migration hibernate -> jOOQ just to demonstrate an idea will not work in any any medium to large sized team / company / project.

You have to first convince people, e.g. by replacing time-critical pieces and showing how cool jOOQ is. And in the end get the chance to use it and assimilate some ORM code.

> , and having the ugliness of full qualification in the code helps with that. 

you try turning a disadvantage into an advantage. why put an artificial constraint on code like a code nazi? People will hate you for that and associate the mess with the introduction of jOOQ. Not the best start to begin with.

> > convince the security team (optional), 

> That should be easy. It's essentially just part of your set of build tools. 

that REALLY depends on the type of company. having to do serious amounts of bureaucracy (even for a small module, especially in a bank or insurance company) can easily be enough reason for a team leader to say 'no' to jOOQ. just having stock jOOQ which works out-of-the-box will encounter the least resistance.

> That's the "Maven way": if something doesn't fit into its (rather narrow) definition of build lifecycle, fragment the project into mini projects that each deploy to the repository. 

And we all know how "great" the maven way(tm) sometimes is.

That will for out current project (and probably others) mean: restructure the whole build in the VCS so the current one-pom-only project (~ 700.000 lines of code) will be a super-pom-project with one module being the project and one module being a single file with one effective line containing the naming strategy ('J' + super.get...() ). wow, that will be pretty and people will just love it :-)

> If you don't want to go that route, Maven is not the right tool for your situation

You should not confuse your personal pet project with a company project being restricted by guidelines. These guidelines are sometimes nasty but are there for a reason. for example a company often restricts the available build tools so other developers can easily grok your project without having to learn grade, buildr, sbt, etc. first. Available skill sometimes matters more than decent technology.

Claiming another build tool just because the default naming strategy is not fitting well will certainly be rejected (and I even fully support that decision)

Honestly, all these things you mention (migrate the whole project from hibernate to jOOQ, restructure your project for submodules, change the build tools) are *imho* total overkill when all it takes is a simple one-liner that probably will make many people with similar problems very happy.

I think one goal of jOOQ should always be to keep things as simple as possible. When adding a one-liner-class will potentially avoid all these crazy steps above and attract more people, especially from the ORM (hibernate, JPQ, eclipselink = many potential customers) world, it certainly will be a good investment.

just my 2ct :-)

Cheers

Peter 

[Peter Ertl]

> > Also it would not stand against a generic solution but be an option. 

> Precisely.

I would consider it an intermediary solution.

Once the generic solution is there we could deprecate and drop the JPrefixGeneratorStrategy again. There would not be much whining when we have a more powerful alternative.

[Durchholz, Joachim]

Peter,

I started answering, but as I worked through your message I found unfounded assumptions about my project, my experiences and about what I'm actually suggesting, which made me angry enough that that response would have been of little general interest and I scrapped it.
Instead, I'm going to discuss basic principles, taking your use case just as the spark for a general line of thought.

What I have to say is that I'm seeing Jooq acquiring features, and I just hope that this isn't going to develop feature bloat.
The problem with feature bloat is that features can interact. If you have N features, there's a potential for N(N-1) interactions, most of them usually unwanted. Even a one-liner change is a new feature; the problem isn't in the one-liner, it's in the ramifications elsewhere.
Now you can say that Jooq is well-designed, and the list of actual interactions is small, and I'd agree with that - mostly; even the best library designer can't keep up with an arbitrary number of things to consider, and the quadratic behaviour will reach that point very quickly. Also, learners have to explore the full N(N-1) space to know which approach of using features is best - that's one of the reasons why learning a large, feature-rich library like Hibernate can easily take a year or more until you're finally reasonably sure about what to do and what not to do with it.

The traditional technique do deal with that quadratic explosion is modularity.
I.e. make class naming a separate tool, apart from and visibly independent of Jooq. That way, learners can take out naming issues as a potential problem, cutting down on the number of possibly unwanted interactions.
Or, alternately, make the various features of Jooq visibly separate and independent. I'd be all for adding class naming under such a structure.

At this time, however, I'm seeing a lot of stuff getting integrated into Jooq's core.
Maybe that's just because I'm missing a lot; that's a very real possibility since I haven't had the opportunity to use Jooq for production yet. My instinctive gut feeling to all these extensions that are being proposed and integrated right now, however, is: "Oh dear I'll have to learn ALL THAT, that's going to be another Hibernate experience where I can't know what I'm actually doing, Jooq promised to be easy and in 1:1 correspondence with SQL but it's not picking up new features at an alarming rate, where is this whole thing headed??"
I'm not taking that gut reaction as the real thing, but it is nourishing a growing concern.

Regards,
Jo

TL;DR: I still think that bloating Jooq just to cover up for Maven's shortcomings is madness.

[Peter Ertl]

Hi Joachim,

I think we both clearly showed our attitude. So here my final words (before things start getting emotional):

I don't think we will bloat jOOQ by adding a very small class having a one-line payload and being very simple. Neglecting it just because it's bloat sounds a little too academic for me.

The addition of the class will immediate solve a real-world problem for people working with maven (which are quite many) and JPA / hibernate / eclipselink / etc. (which are many as well).

Just saying "you use maven / jpa / hibernate instead of [INSERT PRODUCT HERE] so it's your own fault... you gotta do some really ugly work just to integrate jooq nicely" is not the best way to adapt new users.

The current naming strategy integration *imho* is not adequate for maven-only projects.

Rolling a better naming strategy which integrates nicer into maven should be the final solution. However this is no easy task. Once we get there nuking the silly one-liner should not be a great deal.

So yes, I would like to add some temporary "bloat". And "yes" it will solve some issues immediately.

Cheers

Peter

[Lukas Eder]

As a general note: bashing Maven, Hibernate, etc. is off-topic for
this list. Getting personal and emotional even more. If in doubt,
please consider reading these rules:
http://www.apache.org/dev/contrib-email-tips.html

Apart from that, the appropriate place for rants is reddit ;-)

This is my definite stand on this discussion:

1. Not all jOOQ users use Maven.
2. Maven has its place just like Hibernate. Those tools deserve more respect.
3. I don't have time to implement #1171
(https://github.com/jOOQ/jOOQ/issues/1171) right now, but users had
been requesting it for a long time
4. Libraries should ease the pain of their users. GeneratorStrategy
had been causing pain to many users before, both Maven and non-Maven
5. jOOQ-codegen isn't really jOOQ's core. Some have looked at its the
code generating code before and considered the whole module ...
"bloat" ;-) So the jOOQ-codegen module will survive my adding this
particular strategy class.
6. Peter's suggestion is a low-hanging fruit. I will add it as of
#2366 (https://github.com/jOOQ/jOOQ/issues/2366). I will add it to an
org.jooq.util.example package, which will be shipped with
jOOQ-codegen. It is to be understood as a working example.

Joachim, let's have a look at this paragraph:

> "Oh dear I'll have to learn ALL THAT, that's going to be
> another Hibernate experience where I can't know what I'm
> actually doing, Jooq promised to be easy and in 1:1
> correspondence with SQL but it's not picking up new
> features at an alarming rate, where is this whole thing
> headed??"

What exactly do you mean by "all that"? Feel free to create a new
thread on this list, discussing concrete things that you feel should
not be implemented in jOOQ. I am always open to suggestions and I have
removed a lot of "bloat" already in jOOQ 3.0. Some examples can be
seen here:

All incompatible changes between 2.x and 3.0-RC1:
https://github.com/jOOQ/jOOQ/issues?labels=T%3A+incompatible+change%2CR%3A+fixed&milestone=17&page=1&state=closed

Removal of deprecated code
https://github.com/jOOQ/jOOQ/issues/1887

Note that optimistic locking is already a deprecation candidate for 4.0

Cheers
Lukas

2013/4/3 Peter Ertl <pete...@googlemail.com>:

[Lukas Eder]

Hello

#2366 is implemented for jOOQ 3.0:
https://github.com/jOOQ/jOOQ/issues/2366

It includes Peter's contribution and my own example addition, taking
prefix and suffix arguments for most GeneratorStrategy methods as JVM
parameters. These implementations are to be understood as working
examples, and as such, might be modified / adapted in the future. So,
use them at your own risk.

For details, see:
https://github.com/jOOQ/jOOQ/blob/master/jOOQ-codegen/src/main/java/org/jooq/util/example/JPrefixGeneratorStrategy.java
https://github.com/jOOQ/jOOQ/blob/master/jOOQ-codegen/src/main/java/org/jooq/util/example/JVMArgsGeneratorStrategy.java

Cheers
Lukas

2013/4/3 Lukas Eder <lukas...@gmail.com>:

[Durchholz, Joachim]

> Joachim, let's have a look at this paragraph:
>
>> "Oh dear I'll have to learn ALL THAT, that's going to be another
>> Hibernate experience where I can't know what I'm actually doing, Jooq
>> promised to be easy and in 1:1 correspondence with SQL but it's not
>> picking up new features at an alarming rate, where is this whole thing
>> headed??"
>
> What exactly do you mean by "all that"?

On http://jooq.org, Jooq advertises itself as a tool to generate SQL using a fluent API.
That's a self-contained task that's small enough to be described in a single sentence.
Okay, that task has hidden complexities, the long list of specifically supported databases is a hint in that direction... but it's still a single, well-defined task

Now when I take a closer look, I see "extra" features like
- code generation
- caches
- object identity issues
- cross-database compatibility
- parameter inlining
- record mapping
- data type conversion
- String interning
- (there may be more, that was just the result of a quick scan of the user manual)

Learning how the various SQL features translate to Jooq's DSL and how to get data into and out of it is already quite a task.
Each of the extra features are undisputedly useful - but only to a subset of Jooq users; yet every Jooq user has to learn them all to master Jooq.

I'm not advocating removal of these features!
But I'm getting alarmed about the rate at which new features are being accepted into Jooq; maybe just a statement about where the limit is would help.

There might be another remedy, but it would be a LOT of work: Separating Jooq into several libraries.
A DSL core to create AST-like representations of SQL queries.
A JDBC part that sends such data structures to JDBC.
A reveng part that returns a data model.
Most extras could then be recast as separate libraries that can be attached via an API which is (hopefully) focused; the goal would be that it's possible to roll your own extras. I.e. you could write your own code generator, or use the existing default code generator and modify or subclass it to add class prefixes, without the need to ask for a new Jooq feature. Empower the user :-)
It's a trade-off, weighing the amount of work to make it happen, more APIs restricting future Jooq evolution, the risk that the whole thing becomes pointless if the APIs evolve into something more complex than the features they support, against the ability to empower the user with a more fine-grained control of what Jooq does. Ultimately, it's not my call to decide that; I'm just pointing out a possible strategy here :-)

Regards,
Jo

[Peter Ertl]

That's awesome Lukas, thank you! :-)

[Lukas Eder]

Hi Joachim,

2013/4/4 Durchholz, Joachim <Joachim....@hennig-fahrzeugteile.de>:

>> Joachim, let's have a look at this paragraph:
>>
>>> "Oh dear I'll have to learn ALL THAT, that's going to be another
>>> Hibernate experience where I can't know what I'm actually doing, Jooq
>>> promised to be easy and in 1:1 correspondence with SQL but it's not
>>> picking up new features at an alarming rate, where is this whole thing
>>> headed??"
>>
>> What exactly do you mean by "all that"?
>
> On http://jooq.org, Jooq advertises itself as a tool to generate SQL using a fluent API.
> That's a self-contained task that's small enough to be described in a single sentence.

You're cheating a little bit, or you perform "selective vision" of
some sort :-) There is a very prominent section further down:

What is jOOQ?
===========

jOOQ stands for Java Object Oriented Querying. It combines these
essential features:

- Code Generation: jOOQ generates a simple Java representation of your
database schema. Every table, view, stored procedure, enum, UDT is a
class.
- Active records: jOOQ implements an easy-to-use active record
pattern. It is NOT an OR-mapper, but provides a 1:1 mapping between
tables/views and classes. Between columns and members.
- Typesafe SQL: jOOQ allows for writing compile-time typesafe querying
using its built-in fluent API.
- SQL standard: jOOQ supports all standard SQL language features
including the more complex UNION's, nested SELECTs, joins, aliasing
- Vendor-specific feature support: jOOQ encourages the use of
vendor-specific extensions such as stored procedures, UDT's and
ARRAY's, recursive queries, and many more.
===========

Note that I haven't touched the above list since almost the beginning
of jOOQ in 2009 (maybe I should). Let's have a look at how this
compares to your list of "extra" features

> Okay, that task has hidden complexities, the long list of specifically supported databases is a hint in that direction... but it's still a single, well-defined task
>
> Now when I take a closer look, I see "extra" features like
> - code generation
> - caches
> - object identity issues
> - cross-database compatibility
> - parameter inlining
> - record mapping
> - data type conversion
> - String interning
> - (there may be more, that was just the result of a quick scan of the user manual)

By the original mission of jOOQ 1.x and 2.x, most of the above don't
really qualify as "extra". OK, record mapping and data type conversion
are a bit controversial, maybe.

> Learning how the various SQL features translate to Jooq's DSL and how to get data into and out of it is already quite a task.
> Each of the extra features are undisputedly useful - but only to a subset of Jooq users; yet every Jooq user has to learn them all to master Jooq.
>
> I'm not advocating removal of these features!
> But I'm getting alarmed about the rate at which new features are being accepted into Jooq; maybe just a statement about where the limit is would help.

The rate is actually lower than it used to be with jOOQ 1.x. jOOQ is
really maturing. Not many major features are getting into jOOQ in
minor releases. String interning, for instance is really not a major
feature. You don't have to master this, you can just ignore it for a
long time...

But I see where you're going.

> There might be another remedy, but it would be a LOT of work: Separating Jooq into several libraries.
> A DSL core to create AST-like representations of SQL queries.
> A JDBC part that sends such data structures to JDBC.
> A reveng part that returns a data model.
> Most extras could then be recast as separate libraries that can be attached via an API which is (hopefully) focused; the goal would be that it's possible to roll your own extras. I.e. you could write your own code generator, or use the existing default code generator and modify or subclass it to add class prefixes, without the need to ask for a new Jooq feature. Empower the user :-)
> It's a trade-off, weighing the amount of work to make it happen, more APIs restricting future Jooq evolution, the risk that the whole thing becomes pointless if the APIs evolve into something more complex than the features they support, against the ability to empower the user with a more fine-grained control of what Jooq does. Ultimately, it's not my call to decide that; I'm just pointing out a possible strategy here :-)

Rest assured, that some of this is indeed my long-term strategy. While
the little features are nice and important as well, the long-term
strategy really is to separate concerns to an extent where some of the
core API can be implemented by other implementors, than the "jOOQ
reference implementation". As a matter of fact, even parts of the core
API could be extracted to form a JSR which has been missing for a long
time in the Java ecosystem - in my opinion. A JSR for SQL meta data.
Data types, columns, tables, schemas, catalogs, you name it, in an OO
way (JDBC DatabaseMetaData??? Come ooon!). Such a JSR-backed API could
then also be implemented by Derby, H2, HSQLDB, Liquibase, Flyway, and
lots of other tools that repetitively implement SQL meta data.

Another part is the Record mapping. I am not going to implement the
mapping of jOOQ Records to object trees. Instead, users can implement
their own RecordMappers, passing them to the org.jooq.Result. Once
Java 8 is out, even those RecordMappers will become obsolete, as you
can use Streams and Lambdas to transform List<A> into anything else.

The current sample implementation from Record.into() could indeed be
extracted into another, non-core module, just like the org.jooq.DAO
type and various other components. With this POJO business, my own
laziness and lack of interest is a driving force to make jOOQ users
complain on the Jackson / Modelmapper mailing lists about the
impossibility of useful Record <-> POJO mapping, rather than here :-)

However. Extracting these things takes time. And then, concrete
use-cases matter, too. The perfect, definitive API can never be
touched / changed again. And then. Five years later, it turns out that
it was all wrong. So things evolve step by step, here.

Lots of ideas, so, yes, keep on coming with suggestions. And
contributions, of course! :-)

Cheers
Lukas

[Durchholz, Joachim]

> However. Extracting these things takes time.
> And then, concrete use-cases matter, too.

I couldn't agree less!

> Lots of ideas, so, yes, keep on coming with suggestions.

Okay, will do.

> And contributions, of course! :-)

Heh. Jooq is already near the top end of the list of projects I'd like to contribute to.
Don't hold your breath tough, that list is crammed.

Regards,
Jo

[Lukas Eder]

2013/4/8 Durchholz, Joachim <Joachim....@hennig-fahrzeugteile.de>:

Ideas, feedback and discussion are contribution, too. That's great!
So, looking forward to the eventual code contribution! :-)

Cheers
Lukas

[joseph...@gmail.com]

Hi

I'm obviously late to the party, yet I've an issue with the generation strategy; I've my own I would like to hook in through Java code (there https://github.com/cluelessjoe/jooq-flyway-typesafe-migration/blob/master/migrator/src/test/java/LatestModelGenerator.java), but I don't find a way.

How should I proceed?

Thanks in advance

best
joseph

[Lukas Eder]

Hi Joseph,

I'll start a new discussion thread for this, as I don't think it's related to the original discussion.

Stay tuned

--

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lukas Eder]

... Oh, I'm sorry, actually, the original discussion fits your request, but then the discussion was hi-jacked. So here's my answer:

The GeneratorStrategy won't allow you to produce your own Java code. It only specifies what each generated Java object's name should be (e.g. class names, package names, method names, setter names, getter names, attribute names, etc.)

If you want to produce your own custom Java code, you have two options:

- Override the JavaGenerator and implement your own (parts).

- Override the JavaGenerator's custom code section methods:

https://www.jooq.org/doc/latest/manual/code-generation/codegen-custom-code

Let me know if you need any help with those.

Cheers,

Lukas

[joseph...@gmail.com]

Hi Lukas

thanks for the answer. Actually I just want to prefix everything with a version, so it looks like a perfect fit. I would like to make it from Java code, but I didn't manage to set it up, even the JPrefixGeneratorStrategy. To provide some context I provided the class I'm using for generation( https://github.com/cluelessjoe/jooq-flyway-typesafe-migration/blob/master/migrator/src/test/java/LatestModelGenerator.java). I tried giving the proper name, through withName, as well as  withGenerate/withStrategy but nothing was working (or even compiling for the last two methods).

How should I configure the JPrefixGeneratorStrategy (or mine) ?

Thanks again

Lukas

Stay tuned

To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.

[Lukas Eder]

Hi Joseph,

The strategy is configured in Generator.withStrategy(new Strategy().withName("fully.qualfied.class.name"))

Hope this helps,

Lukas

To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscribe@googlegroups.com.

[joseph...@gmail.com]

Hi Lukas

Thanks :) This helps... a bit!

Indeed, I would like to run multiple generations with different prefix each time. 

This could be for example something like:
Generator.withStrategy(new Strategy().with(new PrefixGenerator("somePrefix"))

Is something similar possible? I guess I could use some static field somewhere, but I would be sad to have to do so ;)

thanks again
joseph

[Lukas Eder]

Hi Joseph,

Of course you could run multiple generations with different prefixes each time. Just create a new configuration for each generation.

Please note that all these classes are just XJC-generated classes from the code generation configuration XSD:

https://www.jooq.org/xsd/jooq-codegen-3.9.2.xsd

There's no way to configure a strategy like new PrefixGenerator("somePrefix") in XML, so there's also no such way in the programmatic configuration. You could work around this issue by passing some System.setProperty() or some global variable, or whatever.

Another option would be to use the matcher strategies, where you can specify regular expressions. Perhaps that's easier for prefixing class names:

https://www.jooq.org/doc/latest/manual/code-generation/codegen-matcherstrategy

I hope this helps,

Lukas

To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscribe@googlegroups.com.

[joseph...@gmail.com]

Thanks again Lukas

Well, I explored the matcher option and generated the v1 model with it and the v3 model with the PrefixingGeneratorStrategy (hard coded prefix for now) [1].

I'm doing the matcher this way:
        MatchersTableType matchersTableType = new MatchersTableType();
        MatcherRule versionPrefixer = new MatcherRule().withExpression("v" + currentVersion + "_$1");
        matchersTableType
                .withExpression("^(.*)$")
                .withTableClass(versionPrefixer)
                .withTableIdentifier(versionPrefixer)
                .withRecordClass(versionPrefixer)
                .withPojoClass(versionPrefixer)
                .withDaoClass(versionPrefixer)
                .withInterfaceClass(versionPrefixer)
        ;

The PrefixingGeneratorStrategy is like this:
public class PrefixingGeneratorStrategy extends DefaultGeneratorStrategy {

   
    @Override
    public String getJavaClassName(final Definition definition, final Mode mode) {

        return "v3_" + super.getJavaClassName(definition, mode);
    }

    @Override
    public String getJavaIdentifier(Definition definition) {
        return "v3_" + super.getJavaIdentifier(definition);
    }

}

It turns out that the matcher option prefixes less stuff than the PrefixingGeneratorStrategy, notably the keys and sequences aren't prefixed. So the PrefixingGeneratorStrategy wins the best prefix option award :)

However this one could still be better on 2 points:
1 - prefixing the DefaultCatalog, Keys, Sequences and Tables classes as well
-- currently only the the Schema is prefixed
=> can it be done somehow?

2 - using the PrefixingGeneratorStrategy with various runtime prefixes would require to use some global state (static, java properties)
-- this saddens me deeply :( Well, I guess you won't change it soon... But at least the eternal law of xsd is respected: it always comes back to bit in the a** (IMHO). Would you choose it (or something similar) again if you could redo this part? Or would you stick to one language (Java in this case) and its paradigms (DDD powa)? ^^

Thanks again
++
joseph

[1] https://github.com/cluelessjoe/jooq-flyway-typesafe-migration/tree/issue2/addPrefixToVersionedModels/migrator/src/main/generated-sources/org/jooq/example/migrator/model

[Joseph P.]

Hi again Lukas

To overcome the static nature of giving the class name, I thought of a way that you may agree with. 

Indeed, the GenerationTool.run() method could be splitted in many smaller methods. One could then over some hook for anyone or just make these methods protected so someone else could subclass GenerationTool to provide some specific behavior.

For example this chunk of code:

GeneratorStrategy strategy;

Matchers matchers = g.getStrategy().getMatchers();

if (matchers != null) {

    strategy = new MatcherStrategy(matchers);

    if (g.getStrategy().getName() != null) {

        log.warn("WARNING: Matchers take precedence over custom strategy. Strategy ignored: " +

            g.getStrategy().getName());

        g.getStrategy().setName(null);

    }

}

else {

    Class<GeneratorStrategy> strategyClass = (Class<GeneratorStrategy>) (!isBlank(g.getStrategy().getName())

        ? loadClass(trim(g.getStrategy().getName()))

        : DefaultGeneratorStrategy.class);

    strategy = strategyClass.newInstance();

}

generator.setStrategy(strategy);

could easily be changed to something like:

generator.setStrategy(determineStrategy(generator))

Provided determineStrategy is at least protected, I would easily sneak in.

What do you think of it?

Cheers

joseph

sup...@manning.com 

--
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/NAOpCatRcjs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lukas Eder]

Hi Joseph,

I'll comment inline

2017-05-03 23:30 GMT+02:00 <joseph...@gmail.com>:

Thanks again Lukas

Well, I explored the matcher option and generated the v1 model with it and the v3 model with the PrefixingGeneratorStrategy (hard coded prefix for now) [1].

I'm doing the matcher this way:
        MatchersTableType matchersTableType = new MatchersTableType();
        MatcherRule versionPrefixer = new MatcherRule().withExpression("v" + currentVersion + "_$1");
        matchersTableType
                .withExpression("^(.*)$")
                .withTableClass(versionPrefixer)
                .withTableIdentifier(versionPrefixer)
                .withRecordClass(versionPrefixer)
                .withPojoClass(versionPrefixer)
                .withDaoClass(versionPrefixer)
                .withInterfaceClass(versionPrefixer)
        ;

The PrefixingGeneratorStrategy is like this:
public class PrefixingGeneratorStrategy extends DefaultGeneratorStrategy {
   
    @Override
    public String getJavaClassName(final Definition definition, final Mode mode) {
        return "v3_" + super.getJavaClassName(definition, mode);
    }

    @Override
    public String getJavaIdentifier(Definition definition) {
        return "v3_" + super.getJavaIdentifier(definition);
    }

}

It turns out that the matcher option prefixes less stuff than the PrefixingGeneratorStrategy, notably the keys and sequences aren't prefixed. So the PrefixingGeneratorStrategy wins the best prefix option award :)

Yeah, you'll have to specify the sequenceIdentifier as well, I guess. But indeed, the Keys can't be prefixed with the matcher strategy. Nice catch. I've registered a feature request for this:

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

 

However this one could still be better on 2 points:
1 - prefixing the DefaultCatalog, Keys, Sequences and Tables classes as well
-- currently only the the Schema is prefixed
=> can it be done somehow?

No, I'm afraid these are currently hard wired in the JavaGenerator. Another feature request:

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

 

2 - using the PrefixingGeneratorStrategy with various runtime prefixes would require to use some global state (static, java properties)
-- this saddens me deeply :( Well, I guess you won't change it soon... But at least the eternal law of xsd is respected: it always comes back to bit in the a** (IMHO). Would you choose it (or something similar) again if you could redo this part? Or would you stick to one language (Java in this case) and its paradigms (DDD powa)? ^^

Absolutely! I don't share your opinion here. The XSD approach allowed jOOQ's code generator to work with:

- Standalone XML configuration

- Maven XML configuration

- Gradle XML-DSL configuration mapping (e.g. using the https://github.com/etiennestuder/gradle-jooq-plugin)

- Programmatic configuration

Sure, there are limitations. We cannot use all the types of the universe in this configuration, because ultimately, it's just XML. But that's a good thing too. It makes the whole thing much more maintainable, and it was only limiting in edge cases.

Note, in your PrefixingGeneratorStrategy, you get a Definition argument, which references a Database which might give you access to some other resources you could use for a better workaround?

Lukas

[Lukas Eder]

Hi Joseph,

I'm afraid, I'm not too happy to implement such a workaround here. Any additional protected method that exposes some of these internals is just as good as a user actually patching the logic completely.

Note: A code generator overhaul is scheduled for version 4.0...

Thanks,

Lukas

--
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+unsubscribe@googlegroups.com.

[Joseph P.]

Hi Lukas

Thanks again for your answers

So you like your XSD, I'm surprised but so be it. Let's postpone further discussions on the topic until we can speak of it "IRL".

> Note, in your PrefixingGeneratorStrategy, you get a Definition argument, which references a Database which might give you access to some other resources you could use for a better workaround?

Thanks a lot, I dig into this one and... used:
database.withProperties(new Property().withKey(VERSION_PROPERTY_KEY).withValue("v" + version)));

But then :
- there's no getter for the properties, I had to cast the Database like this :
((AbstractDatabase) definition.getDatabase()).getProperties().getProperty(LatestModelGenerator.VERSION_PROPERTY_KEY)
-- could you put getProperty in Database as well?
- I'm unsure about the side effects of adding such a property... Is it safe?
- if ever you've a better way...

> I'm afraid, I'm not too happy to implement such a workaround here. Any additional protected method that exposes some of these internals is just as good as a user actually patching the logic completely.

Somehow I was expecting this, as well as feeling selfish for asking ^^ Good answer Sir!

> Note: A code generator overhaul is scheduled for version 4.0...

Ok, nice. And even the current one might do all I need in the end, even better.

Cheers !

[Lukas Eder]

2017-05-11 23:59 GMT+02:00 Joseph P. <joseph...@gmail.com>:

So you like your XSD, I'm surprised but so be it. Let's postpone further discussions on the topic until we can speak of it "IRL".

Why IRL? Are there any expressions you'd like to use that would be NSFW? ;)

 

Thanks a lot, I dig into this one and... used:
database.withProperties(new Property().withKey(VERSION_PROPERTY_KEY).withValue("v" + version)));

But then :
- there's no getter for the properties, I had to cast the Database like this :
((AbstractDatabase) definition.getDatabase()).getProperties().getProperty(LatestModelGenerator.VERSION_PROPERTY_KEY) 

-- could you put getProperty in Database as well?

You're absolutely right, thanks for pointing this out. Noted:

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

 

- I'm unsure about the side effects of adding such a property... Is it safe?

Ideally, you'll configure them through your generator configuration. See tns:Properties in:

https://www.jooq.org/xsd/jooq-codegen-3.9.2.xsd

(there it is again, the XSD)

 

- if ever you've a better way...

No, that's the intended way. Writing the properties is straigthforward, and that's what they are for. For arbitrary parameters to custom Database implementations. jOOQ uses them out of the box for JPADatabase or XMLDatabase, for instance.

 

> I'm afraid, I'm not too happy to implement such a workaround here. Any additional protected method that exposes some of these internals is just as good as a user actually patching the logic completely.

Somehow I was expecting this, as well as feeling selfish for asking ^^ Good answer Sir!

You can always try :)

Thanks,

Lukas

[joseph...@gmail.com]

2017-05-11 23:59 GMT+02:00 Joseph P. <joseph...@gmail.com>:

So you like your XSD, I'm surprised but so be it. Let's postpone further discussions on the topic until we can speak of it "IRL".

Why IRL? Are there any expressions you'd like to use that would be NSFW? ;)

Not at all :) First of all: you're happy with xsd and that's a very good thing. I'm curious and have questions about it but that's mostly a personal matter. Not really in sync with this nice jooq user group :)
 

 

Thanks a lot, I dig into this one and... used:
database.withProperties(new Property().withKey(VERSION_PROPERTY_KEY).withValue("v" + version)));

But then :
- there's no getter for the properties, I had to cast the Database like this :
((AbstractDatabase) definition.getDatabase()).getProperties().getProperty(LatestModelGenerator.VERSION_PROPERTY_KEY) 

-- could you put getProperty in Database as well?

You're absolutely right, thanks for pointing this out. Noted:

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

thanks :)

 

- I'm unsure about the side effects of adding such a property... Is it safe?

Ideally, you'll configure them through your generator configuration. See tns:Properties in:

https://www.jooq.org/xsd/jooq-codegen-3.9.2.xsd

(there it is again, the XSD)

The XSD didn't help but the code did ;)

 

- if ever you've a better way...

No, that's the intended way. Writing the properties is straigthforward, and that's what they are for. For arbitrary parameters to custom Database implementations. jOOQ uses them out of the box for JPADatabase or XMLDatabase, for instance.

nice, thanks. :) No dark magic in the background somewhere, very good ^^

 

> I'm afraid, I'm not too happy to implement such a workaround here. Any additional protected method that exposes some of these internals is just as good as a user actually patching the logic completely.

Somehow I was expecting this, as well as feeling selfish for asking ^^ Good answer Sir!

You can always try :)

naah I shouldn't have. Let's say it was a small matter of desperation (only other option at the time was some constant).

Anyway, at the end of the day my little POC, https://github.com/cluelessjoe/jooq-flyway-typesafe-migration, is improved, thanks a lot!
 
++

[Lukas Eder]

2017-05-14 23:17 GMT+02:00 <joseph...@gmail.com>:

2017-05-11 23:59 GMT+02:00 Joseph P. <joseph...@gmail.com>:

So you like your XSD, I'm surprised but so be it. Let's postpone further discussions on the topic until we can speak of it "IRL".

Why IRL? Are there any expressions you'd like to use that would be NSFW? ;)

Not at all :) First of all: you're happy with xsd and that's a very good thing. I'm curious and have questions about it but that's mostly a personal matter. Not really in sync with this nice jooq user group :)

Oh, I see. Sure, I'm more than happy to discuss :)

 

Anyway, at the end of the day my little POC, https://github.com/cluelessjoe/jooq-flyway-typesafe-migration, is improved, thanks a lot!

That's great! I'm looking forward to having another look this week,

Cheers,

Lukas