There are essentially two things: 1. What we discussed before are the actual table / column *names* as used in SQL strings 2. What you call "constants" now is what we call "identifiers" in the code generator.
The current default for the code generator's naming strategy grew historically: - Classes are PascalCased - Identifiers are UPPER_CASED_WITH_UNDERSCORE When we designed this default, we didn't think of the possibility of databases like SQL Server, where people tend to PascalCase also their table / column names. It was designed for databases with UPPER_CASED_WITH_UNDERSCORE table / column names. We're thinking about changing that default such that the identifiers will look exactly as in the database: https://github.com/jOOQ/jOOQ/issues/3570 You can already achieve this today by writing your own naming strategy: - http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy/ - http://www.jooq.org/doc/latest/manual/code-generation/codegen-matcherstrategy/ 2014-12-03 2:31 GMT+01:00 Gavriel Fleischer <[email protected]>: > About the case sensitivity: > > I would rather see the constants that are generated by jooq to have the > same case as the table, column names are in the DB. Currently when I have a > table called StatisticsByWebsite and a column WebsiteShortUrl, then the > generated classname would be Statisticsbywebsite, that is hard to read, and > not according to most people (at least that I know) Java coding standard. > StatisticsByWensite would be a better class name. > > As for the constants... well there it's not that clear, because on one > hand constants usually have full capital name, on the other hand where they > have words, then they are separated by underline, so the constants could be > STATISTICS_BY_WEBSITE.WEBSITE_SHORT_URL. > > Regards, > Gavriel > > On Tue Dec 02 2014 at 9:23:02 AM Lukas Eder <[email protected]> wrote: > >> There is certainly room for improvement in that area. The two modes of >> operation are very similar in the way they're used throughout the API as >> both operations simply require String arguments, and String doesn't have >> have a semantics per se. >> >> An example of where this is also subtle: >> >> DSL.select() >> .from("plain SQL table") -- DSL.table("...") semantics >> >> >> vs. >> >> DSL.dropTable("tableByName") -- DSL.tableByName("...") semantics >> >> >> One way to disambiguate this would be to deprecate the tableByName and >> fieldByName methods (and all methods that accept strings with a "Name" >> semantics), and offer alternative API methods accepting the org.jooq.Name >> type: >> >> DSL.table(DSL.name("tableByName")); >> DSL.field(DSL.name("fieldByName"), Integer.class); >> >> >> This would make using the jOOQ API a bit more verbose, but it might still >> be acceptable. >> >> Another option would be to change the default for RenderNameStyle from >> QUOTED to AS_IS. This is the setting that produces case-sensitive names in >> the first place. Changing that default would be very delicate and I'm not >> so sure if it's a good idea. >> >> 2014-12-01 19:54 GMT+01:00 Alok Menghrajani <[email protected]>: >> >>> Can we make this a little less subtle by renaming DSL.field() to >>> something more explicit? Here are a few suggestions: >>> DSL.fieldRaw(), DSL.fieldUnescaped(), DSL.fieldRawSql() or >>> DSL.fieldUnescapedSql(). >>> >> >> I think that the plain SQL method names should be as simple as possible. >> They are much more generally useful than the fieldByName / tableByName >> methods, which is why they deserve the short name. Anything that adds words >> to them will make them very hard to read. >> >> It will also solve the problem of people picking the first thing that >>> shows up & seems to work in their type ahead; forcing them to stop and >>> think about what they are doing >>> >> >> I agree, but I'd like to take this opportunity to help people understand >> that most databases are case-insensitive by default, and that jOOQ is >> helping them getting case sensitivity right - because ultimately, that is >> what they want when columns are deserialised to Java again: Case sensitive >> column names. >> >> Is there any way this can be improved via the jOOQ API. >> >> Are there any other ideas in the group? >> >> Cheers, >> Lukas >> >> -- >> 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/469obN2diSM/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
