ugly jOOQ 3.3.1 bug in generated class column name accessors

[Garret Wilson]

We have column names like "foo:bar"

I accidentally used jOOQ 3.1.0 to generate class names. I created a new ExampleRecord and called exampleRecord.Foo_bar() to set the "foo:bar" column. OK, that looks reasonable.

Then I tried to compile and ran into the problems that arise when mixing version numbers. So I updated the code generator to version 3.3.1 to match the library used in my code.

Now instead of exampleRecord.Foo_bar() I have to use exampleRecord.Foo_3abar(). (groan)

The source of the bug is easy to guess: somewhere the generator is URI-encoding encoding the column names (but why!??) yielding "foo%3abar", so that when they get "cleaned up" and camelCased for Java this gets turned into "foo_3abar".

Ugh, this is just ugly. Could we get a patch release quickly that fixes this bug? Otherwise we're going to have to have tons and tons of code that looks terrible, which will have to be updated when the bug is fixed. (I'm just now going through and changing all my colleagues' JDBC code to jOOQ; this isn't going to help it sell well on my team.)

[Lukas Eder]

Hi Garret,

2014-04-28 0:48 GMT+02:00 Garret Wilson <gar...@globalmentor.com>:

We have column names like "foo:bar"

I accidentally used jOOQ 3.1.0 to generate class names. I created a new ExampleRecord and called exampleRecord.Foo_bar() to set the "foo:bar" column. OK, that looks reasonable.

Then I tried to compile and ran into the problems that arise when mixing version numbers. So I updated the code generator to version 3.3.1 to match the library used in my code.

Now instead of exampleRecord.Foo_bar() I have to use exampleRecord.Foo_3abar(). (groan)

The source of the bug is easy to guess: somewhere the generator is URI-encoding encoding the column names (but why!??)

This is the general name mangling strategy to avoid conflicts when someone has all of foo:bar, foo_bar, and foo?bar columns. This was implemented in jOOQ 3.3.0:

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

 

yielding "foo%3abar", so that when they get "cleaned up" and camelCased for Java this gets turned into "foo_3abar".

Ugh, this is just ugly. Could we get a patch release quickly that fixes this bug?

At Data Geekery, we're more than happy to offer you custom engineering services for urgent tasks. Please find some information on this website:

http://www.jooq.org/support

... or contact sa...@datageekery.com. Apart from the features that are already in place to work around such issues (see below), I'm sure we can find an agreement quickly.

 

Otherwise we're going to have to have tons and tons of code that looks terrible, which will have to be updated when the bug is fixed.

You can work around this issue by explicitly renaming generated objects using matcher strategies:

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

Or your own programmatic strategies:

http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy/

 

(I'm just now going through and changing all my colleagues' JDBC code to jOOQ; this isn't going to help it sell well on my team.)

I'm aware that you've used the term "show-stopper" before for something that might have not appeared like a critical issue in ordinary contexts. I personally believe that this name-mangling scheme isn't such a critical issue.

Maybe, you have more general concerns or doubts towards jOOQ, that you would like to address? I would like to offer help with any substantial issues you may have.

Best Regards,
Lukas

[Garret Wilson]

On Sunday, April 27, 2014 11:44:26 PM UTC-7, Lukas Eder wrote:

...

This is the general name mangling strategy to avoid conflicts when someone has all of foo:bar, foo_bar, and foo?bar columns. This was implemented in jOOQ 3.3.0:

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

Hmmm... I empathize with the intent, but ... I'm not sure it should be the default behavior if ease-of-use is the goal. I'd imagine that the type of conflicts you mention are a tiny minority of cases. I'd recommend changing all invalid characters to '_' as you used to do, and allowing a simple flag for turning on/off illegal character URI-encoding.
 

 ...

Or your own programmatic strategies:

http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy/

Ooh, that looks promising! Thanks! I'll investigate that immediately.
 

 ...

I'm aware that you've used the term "show-stopper" before for something that might have not appeared like a critical issue in ordinary contexts. I personally believe that this name-mangling scheme isn't such a critical issue.

I'm not aware that I've used the term "show-stopper" at any time related to jOOQ. This particular behavior in no way a show-stopper, and never meant to imply such. I only said that having method names with arbitrary characters (seemingly) having nothing to do with the column name wouldn't help the library sell well to the team. (Currently I'm the sole person using and evangelizing jOOQ on my team.)

In any case, your reply (as usual) has been quick, accurate, and helpful. Thanks so much!

Garret

[Lukas Eder]

2014-04-28 15:35 GMT+02:00 Garret Wilson <gar...@globalmentor.com>:

On Sunday, April 27, 2014 11:44:26 PM UTC-7, Lukas Eder wrote:

...

This is the general name mangling strategy to avoid conflicts when someone has all of foo:bar, foo_bar, and foo?bar columns. This was implemented in jOOQ 3.3.0:

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

Hmmm... I empathize with the intent, but ... I'm not sure it should be the default behavior if ease-of-use is the goal. I'd imagine that the type of conflicts you mention are a tiny minority of cases. I'd recommend changing all invalid characters to '_' as you used to do, and allowing a simple flag for turning on/off illegal character URI-encoding.

I'll trade your tiny minority of people that produce collisions with special characters against my tiny minority of people who use special characters in object names more than very occasionally :-)

On a more serious note, there is a lot of name mangling and encoding going on, in jOOQ's code generator. Our main goal here is to avoid compilation errors at all costs. Encoding all non-Java-identifier characters with an underscore was simply not very robust. Besides, it was just as much a random choice as choosing the "<underscore> <hex-encoding>" format that we have in place now.

I'd prefer not to revert this change. The code generator works well and is robust, out-of-the-box. When we implemented the matcher strategies, we wanted to help people override this out-of-the-box behaviour as easily and as powerfully as possible, instead of adding dozens of little (hard-to-test) flags for every use-case.

A similar discussion is the one where jOOQ's code generator transforms table names into PascalCase classes, but table references are UPPER_CASED, by default. A default setting that doesn't suit everyone. Again, the matcher strategies help overriding this default in a very generic way.

 

 

 ...

Or your own programmatic strategies:

http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy/

Ooh, that looks promising! Thanks! I'll investigate that immediately.

Yes, I think that would be the best way forward.

Cheers

Lukas

[Garret Wilson]

On Monday, April 28, 2014 7:25:46 AM UTC-7, Lukas Eder wrote:

 

 

 ...

Or your own programmatic strategies:

http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy/

Ooh, that looks promising! Thanks! I'll investigate that immediately.

Yes, I think that would be the best way forward.

Hmmm... this is not working. I'm sure I'm doing something wrong. I just want to force the conversion of foo:bar to FOO_BAR (e.g. setFOO_BAR). So following the examples, I try:

<strategy>
  <matchers>
    <fields>
      <expression>^(.+):(.+)$</expression>
      <fieldIdentifier>
        <transform>UPPER</transform>
        <expression>$1_$2</expression>
      </fieldIdentifier>
    </fields>
  </matchers>
</strategy>

That gives me an error: Cannot configure instance of org.jooq.util.jaxb.MatchersFieldType from ^(.+):(.+)$

Oddly enough, the expression ^(.*?)_BOOK_(.*)$ straight from the online manual doesn't work, either.

[Garret Wilson]

On Monday, April 28, 2014 7:25:46 AM UTC-7, Lukas Eder wrote:

2014-04-28 15:35 GMT+02:00 Garret Wilson <gar...@globalmentor.com>:

On Sunday, April 27, 2014 11:44:26 PM UTC-7, Lukas Eder wrote:

...

This is the general name mangling strategy to avoid conflicts when someone has all of foo:bar, foo_bar, and foo?bar columns. This was implemented in jOOQ 3.3.0:

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

Hmmm... I empathize with the intent, but ... I'm not sure it should be the default behavior if ease-of-use is the goal. I'd imagine that the type of conflicts you mention are a tiny minority of cases. I'd recommend changing all invalid characters to '_' as you used to do, and allowing a simple flag for turning on/off illegal character URI-encoding.

I'll trade your tiny minority of people that produce collisions with special characters against my tiny minority of people who use special characters in object names more than very occasionally :-)

I think you grandly misinterpreted what I was saying. In no way am I saying not to encode special characters. I am not even asserting that people who use special characters are a minority. What I was saying is that the people who use name their fields in such a way as to generate conflicts with a naive encoding strategy (e.g. someone who would name their columns "foo:bar", "foo$bar" and "foo@bar" in the same table) must be a very small number of people---and those few people would surely not be surprised if the default naming strategy produced conflicts.

By no means turn off some sort of replacement of special characters. I just think that the few people who do something that is confusing anyway (using names that conflict when replacing special characters) wouldn't mind the extra step of setting a "uriCodeSpecialCharacters" switch, and it wouldn't make the generated classes all ugly for those of us using special characters in a reasonable, non-conflicting way.

Just my opinion. If the workaround (below) works, it will work for me. The point of jOOQ is to make things easy, pretty, and understandable; and I'm just trying to provide feedback to further that goal. Cheers!

[Garret Wilson]

On Monday, April 28, 2014 8:26:59 AM UTC-7, Garret Wilson wrote:

I think you grandly misinterpreted ...

Sorry, I was thinking in Portuguese, and I just meant that it was a large misinterpretation; I didn't intend the ostentatiousness that the English word "grandly" connotes. :)

[Rob Sargent]

I'm glad you sent this:  There was no way most of us Anglophones would have picked up on that since your English is excellent.  I re-re-read the reference and could not see how you would have felt "grandly misinterpreted"

--
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/d/optout.

[Rob Sargent]

Did you try "\" before the parentheses?  (I'm not where I can test this right now)

[Garret Wilson]

On Monday, April 28, 2014 8:36:10 AM UTC-7, Rob Sargent wrote:

... your English is excellent. ...

Thanks. hehe I'm really just a boy from the American Southwest. I recently returned from a trip to Brazil, and in Portuguese "grande" (as in Spanish) simply means "large".

So much work, so many thoughts, so little time to write it all down correctly. :)

Best,

G

[Garret Wilson]

On Monday, April 28, 2014 8:38:11 AM UTC-7, Rob Sargent wrote:

Did you try "\" before the parentheses?  (I'm not where I can test this right now)

I did just now, and it doesn't do any better. Besides, one wouldn't want to escape the parentheses---they are essential for the matching groups.

In fact, I took the entire final example verbatim and put it in my <generator> configuration section in Maven, and I get the same error.

I think I must be making some grand mistake. :D

[Rob Sargent]

A yes, but did you escape the escapes? "\\\"

[Lukas Eder]

It happens to me all the time. Please, excuse my German ;-)

[Garret Wilson]

On Monday, April 28, 2014 8:49:50 AM UTC-7, Rob Sargent wrote:

A yes, but did you escape the escapes? "\\\"

It doesn't even accept ".*".

G

[Garret Wilson]

I can't even seem to find org.jooq.util.jaxb.MatchersFieldType in the online documentation...

[Lukas Eder]

2014-04-28 17:18 GMT+02:00 Garret Wilson <gar...@globalmentor.com>:

On Monday, April 28, 2014 7:25:46 AM UTC-7, Lukas Eder wrote:

 

 

 ...

Or your own programmatic strategies:

http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy/

Ooh, that looks promising! Thanks! I'll investigate that immediately.

Yes, I think that would be the best way forward.

Hmmm... this is not working. I'm sure I'm doing something wrong. I just want to force the conversion of foo:bar to FOO_BAR (e.g. setFOO_BAR). So following the examples, I try:

<strategy>
  <matchers>
    <fields>
      <expression>^(.+):(.+)$</expression>
      <fieldIdentifier>
        <transform>UPPER</transform>
        <expression>$1_$2</expression>
      </fieldIdentifier>
    </fields>
  </matchers>
</strategy>

That gives me an error: Cannot configure instance of org.jooq.util.jaxb.MatchersFieldType from ^(.+):(.+)$

This error message looks quite much like the one here:

https://groups.google.com/forum/#!msg/jooq-user/1iy0EdWe_T8/rljooohQed0J

... which was an issue that was fixed in jOOQ 3.3:

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

I'm just checking... Have you upgraded everything to 3.3?

[Garret Wilson]

On Monday, April 28, 2014 9:33:01 AM UTC-7, Lukas Eder wrote:

...

I'm just checking... Have you upgraded everything to 3.3?

Yes, in fact I even just now went into my .m2/repository/org/jooq... directory and manually removed all the versions for all the packages except for 3.3.1, followed by a "mvn clean generate-resources" and got the same error.

[Garret Wilson]

For reference here's the full relevant section from my POM. Note that I'm running the jOOQ generation in a separate profile so that it won't run with a normal Maven build. That is, it is invoked using e.g.: mvn generate-resources -P tools

  <dependency>
    <groupId>org.jooq</groupId>
    <artifactId>jooq</artifactId>
    <version>3.3.1</version>
  </dependency>
</dependencies>

<profiles>
  <profile>
    <id>tools</id>
    <build>
      <plugins>
        <plugin>
          <groupId>org.jooq</groupId>
          <artifactId>jooq-codegen-maven</artifactId>
          <version>3.3.1</version>
          <executions>
            <execution>
              <goals>
                <goal>generate</goal>
              </goals>
            </execution>
          </executions>

          <dependencies>
            <dependency>
              <groupId>org.postgresql</groupId>
              <artifactId>postgresql</artifactId>
              <version>9.3-1100-jdbc41</version>
            </dependency>
          </dependencies>

          <configuration>
            <jdbc>
              <driver>org.postgresql.Driver</driver>
              <url>jdbc:postgresql://127.0.0.1:5432/exampledb</url>
              <user>user</user>
              <password>password</password>
            </jdbc>

            <generator>
              <name>org.jooq.util.DefaultGenerator</name>
              <database>
                <name>org.jooq.util.postgres.PostgresDatabase</name>
                <includes>.*</includes>
                <excludes></excludes>
                <inputSchema>public</inputSchema>
              </database>

              <strategy>
                <matchers>
                  <fields>
                    <expression>^(.+):(.+)$</expression>
                    <fieldIdentifier>
                      <transform>UPPER</transform>
                      <expression>$1_$2</expression>
                    </fieldIdentifier>
                  </fields>
                </matchers>
              </strategy>

              <target>
                <packageName>com.example.jooq.schema</packageName>
                <directory>${project.build.directory}/generated-sources</directory>
              </target>
            </generator>
          </configuration>
        </plugin>
      </plugins>

[Lukas Eder]

Hi Garret,

I think this is the issue. You wrote (from the manual)

              <strategy>
                <matchers>
                  <fields>
                    <expression>^(.+):(.+)$</expression>
                    <fieldIdentifier>
                      <transform>UPPER</transform>
                      <expression>$1_$2</expression>
                    </fieldIdentifier>
                  </fields>
                </matchers>
              </strategy>

It looks as though the manual is not up to date after the fix in #2910.

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

It should now read:

              <strategy>
                <matchers>
                  <fields>

                    <field>

                      <expression>^(.+):(.+)$</expression>
                      <fieldIdentifier>
                        <transform>UPPER</transform>
                        <expression>$1_$2</expression>
                      </fieldIdentifier>
                    </field>

                  </fields>
                </matchers>
              </strategy>

The lack of this additional XML element was precisely the reason why this matcher strategy configuration didn't work at all with Maven, prior to #2910.

I'm very sorry for this inconvenience. I'll fix the jOOQ 3.3 manual immediately.

- Lukas

[Garret Wilson]

On Monday, April 28, 2014 11:24:02 AM UTC-7, Lukas Eder wrote:

It looks as though the manual is not up to date after the fix in #2910.

Woo hoo! At least the generator runs, now!

But it doesn't give me what I want. With the changes you indicated, I still have an ugly ExampleRecord.setFoo_a3bar().

I don't find the manual very clear about the distinction among <fieldIdentifier>, <fieldMember>, <fieldSetter>, and <fieldGetter>. I had assumed that setting fieldIdentifier would automatically affect all the getters and setters for column names in records. This appears not to be the case. So how do I change field getters and setters? Do I need both a <fieldSetter> and <fieldGetter> section, both containing identical information? (Isn't it natural to think that a developers wants to use the same scheme for both getters and setters by default?) Or am I doing it wrong?

[Garret Wilson]

On Monday, April 28, 2014 1:09:48 PM UTC-7, Garret Wilson wrote:

...

But it doesn't give me what I want. With the changes you indicated, I still have an ugly ExampleRecord.setFoo_a3bar().

I don't find the manual very clear about the distinction among <fieldIdentifier>, <fieldMember>, <fieldSetter>, and <fieldGetter>. I had assumed that setting fieldIdentifier would automatically affect all the getters and setters for column names in records. This appears not to be the case. So how do I change field getters and setters? Do I need both a <fieldSetter> and <fieldGetter> section, both containing identical information? (Isn't it natural to think that a developers wants to use the same scheme for both getters and setters by default?) Or am I doing it wrong?

So it appears that I have to use <fieldSetter> and <fieldGetter> separately, in addition to the other definitions. Worse, with a <fieldGetter> expression of ^(.+):(.+)$ and a transform of UPPER, an output expression of $1_$2 yields ExampleRecord.FOO_BAR(). That's obviously not right! So I tried an output expression of get$1_$2, and that gives me ExampleRecord.GETFOO_BAR(). Ack! And all this because a recent version of jOOQ forces URI-encoding with no option to turn it off.

...and I still don't know what <fieldMember> refers to. If all this is in the manual, I missed it.

[Garret Wilson]

So it appears that the custom matcher strategies do not in fact allow one to work around the the forced URI-encoding of column names. Trying to reproduce getFoo_bar() (which is what jOOQ used to produce for a column named foo:bar) will in fact yield GETFOO_BAR() or GetFooBar(). The only way I can even make it work close to correctly is to use the AS_IS transform to yield getfoo_bar(). This is workable, but frustrating.

I would even go so far as to consider it bugs that the strategies require that "get" and "set" be provided in the output of <fieldSetter> and <fieldGetter>; and that the transform is applied to the "get" and "set" suffixes as well.

OK, I'll use what I got sort of working. But can someone tell me what <fieldMember> applies to?

[Lukas Eder]

2014-04-28 23:48 GMT+02:00 Garret Wilson <gar...@globalmentor.com>:

So it appears that the custom matcher strategies do not in fact allow one to work around the the forced URI-encoding of column names. Trying to reproduce getFoo_bar() (which is what jOOQ used to produce for a column named foo:bar) will in fact yield GETFOO_BAR() or GetFooBar(). The only way I can even make it work close to correctly is to use the AS_IS transform to yield getfoo_bar(). This is workable, but frustrating.

Yes, we've had this discussion recently, on the user group:

https://groups.google.com/d/msg/jooq-user/1iy0EdWe_T8/TtgmseBsjiUJ

We might address this some time soon:

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

I would even go so far as to consider it bugs that the strategies require that "get" and "set" be provided in the output of <fieldSetter> and <fieldGetter>; and that the transform is applied to the "get" and "set" suffixes as well.

How would you go about people not wanting "get" and "set" in their getter and setter names?

 

OK, I'll use what I got sort of working. But can someone tell me what <fieldMember> applies to?

It is used for member names in POJOs and also for method argument names. See:

http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy/

    /**
     * Override this method to define how Java members should be named. This is
     * used for POJOs and method arguments
     */
    @Override
    public String getJavaMemberName(Definition definition, Mode mode) {
        return definition.getOutputName();
    }

[Rob Sargentg]

I took Garret to mean that getters start with "get" and should not be part of the regexp replacement, not exposed to the uppercasing. Same for setters of course.

[Garret Wilson]

On Tuesday, April 29, 2014 12:21:49 AM UTC-7, Lukas Eder wrote:

...

I would even go so far as to consider it bugs that the strategies require that "get" and "set" be provided in the output of <fieldSetter> and <fieldGetter>; and that the transform is applied to the "get" and "set" suffixes as well.

How would you go about people not wanting "get" and "set" in their getter and setter names?

Um... er... as they say in Brazil, "estou sem palavras"---I'm without words. Speechless. hehe At first I thought you were joking. I mean, if the number of people using "foo:bar" and "foo#bar" in the same table is like .1% of users, a use who doesn't want "get" in the getter name (is it still a getter, then?) is like .05% of users. (Numbers used for explanatory value, not for accuracy.)

But this is very easily addressed, and at the same time addresses another issue I raised, namely that you shouldn't have to define both getters and setters when you know the general format of the property. jOOQ should add a property named <fieldProperty>. If defined, it determines what comes after both "get" and "set" in getters and setters, respectively. That is, if I set the <fieldProperty> transform to UPPER, then this produces getFOO() and setFOO() and I don't even have to define <fieldGetter> and <fieldSetter>. For that tiny fraction of people who don't even want "get" and "set" in their accessor names, then they can define <fieldGetter> and/or <fieldSetter>, which will override the rule in <fieldProperty> (or they don't even have to define <fieldProperty> at all). This solution therefore is even 100% backwards compatible. If you add it in the next version, no one even has to change their code if they want to continue using <fieldGetter> and/or <fieldSetter>!

See, the general rule should be, "make the default configuration work as expected for the 99.98% of normal use cases, and provide optional configuration for the .01% of users who want to break convention".
 

 

OK, I'll use what I got sort of working. But can someone tell me what <fieldMember> applies to?

It is used for member names in POJOs and also for method argument names.

Maybe you could point me to an example? I guess I haven't got to POJOs yet---I was thinking the ExampleRecord class was like a POJO.

Anyway, Lukas, thanks so much for all your help and feedback on this. I've got jOOQ set up in our project now, and I've handed the database access part over to a teammate to convert some of our existing SQL to jOOQ. We'll see how it goes.

Thanks again!

Garret

[Lukas Eder]

2014-04-29 15:22 GMT+02:00 Rob Sargentg <robjs...@gmail.com>:

I took Garret to mean that getters start with "get" and should not be part of the regexp replacement, not exposed to the uppercasing. Same for setters of course.

Thanks. I think I understood Garret correctly :-)

[Lukas Eder]

2014-04-29 15:36 GMT+02:00 Garret Wilson <gar...@globalmentor.com>:

On Tuesday, April 29, 2014 12:21:49 AM UTC-7, Lukas Eder wrote:

...

I would even go so far as to consider it bugs that the strategies require that "get" and "set" be provided in the output of <fieldSetter> and <fieldGetter>; and that the transform is applied to the "get" and "set" suffixes as well.

How would you go about people not wanting "get" and "set" in their getter and setter names?

Um... er... as they say in Brazil, "estou sem palavras"---I'm without words. Speechless. hehe At first I thought you were joking. I mean, if the number of people using "foo:bar" and "foo#bar" in the same table is like .1% of users, a use who doesn't want "get" in the getter name (is it still a getter, then?) is like .05% of users. (Numbers used for explanatory value, not for accuracy.)

Two very simple use-cases:

1. Someone prefers "is" over "get" for boolean getters

2. Someone prefers no verb at all. Yes, we're all slaves to JavaBeans. But why? Why not just have:

interface SomeRecord {

    // Setter

    void SOME_COLUMN(int value);

    // Getter

    int SOME_COLUMN();

}

And then, there's this whole group of folks who follow suit with Martin Fowler who proclaimed fluent setters that are prefixed with "with" (and return "this", this is yet another pending feature request: https://github.com/jOOQ/jOOQ/issues/2934)

And then, Scala developers use jOOQ, too. Without the useless "get" / "set" / "is" boilerplate, they can write even more fluent jOOQ interaction code.

Now. While you obviously don't agree with these arguments - which is fine, I can see your point about the .1% vs. .05% - I've been maintaining this beast for 5 years now, and believe me, I've seen my share of feature requests, most specifically in the field of people not agreeing with generator defaults. While jOOQ has hundreds of other great features, somehow, everyone seems to have one or two flags to suggest that would make "that difference". This is why we have these strategies, to avoid tons of unmaintainable flags. In principle, you can override anything if it's that important.

Of course, they may still have 1-2 flaws / bugs :-)

But this is very easily addressed, and at the same time addresses another issue I raised, namely that you shouldn't have to define both getters and setters when you know the general format of the property. jOOQ should add a property named <fieldProperty>. If defined, it determines what comes after both "get" and "set" in getters and setters, respectively. That is, if I set the <fieldProperty> transform to UPPER, then this produces getFOO() and setFOO() and I don't even have to define <fieldGetter> and <fieldSetter>. For that tiny fraction of people who don't even want "get" and "set" in their accessor names, then they can define <fieldGetter> and/or <fieldSetter>, which will override the rule in <fieldProperty> (or they don't even have to define <fieldProperty> at all). This solution therefore is even 100% backwards compatible. If you add it in the next version, no one even has to change their code if they want to continue using <fieldGetter> and/or <fieldSetter>!

That's a good idea! Thanks for bringing that up - and for bearing with me ;-). It would even set the default for <fieldMember>

I've registered #3222:

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

 

See, the general rule should be, "make the default configuration work as expected for the 99.98% of normal use cases, and provide optional configuration for the .01% of users who want to break convention".
 

 

OK, I'll use what I got sort of working. But can someone tell me what <fieldMember> applies to?

It is used for member names in POJOs and also for method argument names.

Maybe you could point me to an example? I guess I haven't got to POJOs yet---I was thinking the ExampleRecord class was like a POJO.

These:

http://www.jooq.org/doc/latest/manual/code-generation/codegen-pojos/

 

Anyway, Lukas, thanks so much for all your help and feedback on this. I've got jOOQ set up in our project now, and I've handed the database access part over to a teammate to convert some of our existing SQL to jOOQ. We'll see how it goes.

Good luck with that! Let us know how it goes!

Cheers

Lukas

[Garret Wilson]

On Tuesday, April 29, 2014 8:06:39 AM UTC-7, Lukas Eder wrote:

... Now. While you obviously don't agree with these arguments ...

Far from it! I've used ObjectPascal since back in the Borland Delphi 1.0 days, and its ability to define a property with separate accessor methods influenced the development of the same thing in C#. The "get" and "set" method pattern is clunky. Five minutes after waking up this morning I simply found it humorous that someone wanted to have a "getter" without "get".

My larger point is that the library should default to convention with the option for configuration, and I think my proposal for <fieldProperty> addresses that concern. Thanks for considering it! Have a productive day.

Garret

[Lukas Eder]

2014-04-29 17:53 GMT+02:00 Garret Wilson <gar...@globalmentor.com>:

On Tuesday, April 29, 2014 8:06:39 AM UTC-7, Lukas Eder wrote:

... Now. While you obviously don't agree with these arguments ...

Far from it! I've used ObjectPascal since back in the Borland Delphi 1.0 days, and its ability to define a property with separate accessor methods influenced the development of the same thing in C#. The "get" and "set" method pattern is clunky. Five minutes after waking up this morning I simply found it humorous that someone wanted to have a "getter" without "get".

OK, fair enough ;-)

 

My larger point is that the library should default to convention with the option for configuration, and I think my proposal for <fieldProperty> addresses that concern. Thanks for considering it! Have a productive day.

Thanks, you too!