The documentation is quite good actually, except for the custom generator
...
I admit I may not be the smartest guy out there but I could not guess that
I needed to override getJavaIdentifier in order to decide the static names
of both table and fields without a bunch of println and debugging. A fairly
large number of different things can be called "Identifiers" in
programming. Finding out that I can instanceof the Definition parameter to
know if we are talking about a field, a table or whatever isn't an easy
guess either (in my first attempts, I relied to the number of dots in the
qualified name to know it).
Also, I expected to be able to set the java property name of a record field
without relying to [get/set]javaGetterName which seemed to be there only in
case you wouldn't want to follow the normal javabean naming convention.
Also, it's not very intuitive to me that I need to override
getJavaClassName and watch for mode=DEFAULT to set the Table class name,
mode=RECORD to set the record name, I discovered it by debugging, before
that I was asking myself why those methods were called hundreds of times
and how I could modify them without interfering with the multiple other
possible scenarios.
It would have been so much easier if there had been distinct methods for
generating record class names, table class names, table static identifiers,
fields static identifiers or field property names with clear purpose and
meaningful names, in that case I admit the current documentation would be
sufficient. However, the documentation doesn't give you many hints when
you need anything more specific than a typical "lowecase all, prefix all".
Remember that people writing their first generator are not necessarily Jooq
experts, they probably just want to override a few names that didn't come
out clean and honestly I am sure such a task doesn't have to be that
complicated.
Perhaps, after all, the solution is as described above : add a subclass of
DefaultGeneratorStrategy that delegates to simpler methods with meaningful
names and parameters?
Otherwise, I think it would be helpful to document the generator methods
and better explain the different scenarios in which they are called.
Other than that, I thought about contributing a basic XML based generator
with some syntax like
<table name="wa_authors">
<class>Authors</class>
<record>AuthorRecord</record>
<staticidentifier>T_AUTHORS</staticidentifier>
<fields>
<field name="idauthor" property="idAuthor">
<...>
</fields>
</table>
I had a few other ideas, like for example delegating generator methods to a
dynamically loaded groovy script to declare a default name conversion
scheme.
However I did not dig the idea too much because I thought the generator was
going to be rewritten from scratch.
Le vendredi 20 septembre 2013 09:48:31 UTC+2, Lukas Eder a écrit :
>
>
>
>
> 2013/9/20 Lukas Eder <[email protected] <javascript:>>
>
>>
>> 2013/9/18 Stéphane Cl <[email protected] <javascript:>>
>>
>>> Hello,
>>> I know there have been many discussions on this list regarding a
>>> possible better, more decoupled code generation engine in the future but it
>>> seems that the old not-so-good system is still going to be there for some
>>> time. Therefore, I would like to suggest one or two improvements.
>>>
>>> First, regarding the XML file you need to specify in the command line, I
>>> think would be nice if you could use java properties to avoid hardcoding
>>> some of the values.
>>>
>>> <jdbc>
>>> <driver>${jdbc.driver}</driver>
>>> <url>${jdbc.url}</url> (...)
>>> </jdbc>
>>>
>>> this would allow you to specify some of them using -Dargs in the command
>>> line and make your XML file more portable. After all, the XML file is
>>> likely to be included in version control and it should be interesting to
>>> run it from any machine, encapsulating specific disk path and jdbc settings
>>> in an appropriate shell script.
>>>
>>
>> I understand your concerns. Unfortunately, properties-based code
>> generator configuration is quite hard to maintain (think of forced types,
>> etc.) and was thus removed with jOOQ 3.0 ("ant task"):
>> http://www.jooq.org/doc/3.1/manual/reference/migrating-to-3.0/#N13700
>>
>> You can, of course, provide the code generator with programmatic
>> configuration. At code gen build time, the XSD (
>> http://www.jooq.org/xsd/jooq-codegen-3.0.0.xsd) is used by an XJC task
>> to produce JAXB-annotated artefacts. In other words, you can unmarshal the
>> XML yourself, using JAXB, and then patch relevant parts programmatically,
>> passing the org.jooq.util.jaxb.Configuration object to
>> the org.jooq.util.GenerationTool.main(Configuration) method.
>>
>>
>>> Second, I think it is currently a pain to implement a default generator
>>> to say "I want this java name for this sql field/table/record" and (I mean
>>> no offense, really!) it's not *extremely well documented*, would it be
>>> possible to configure that from xml?
>>>
>>
>> I am aware of the lack of documentation in this section. I guess your
>> hint is the "last straw", to make me add some sections right now :-)
>>
>
> Also, some heads-up regarding *what* can be improved would be greatly
> appreciated. I've had lots of feedback about the documentation being
> insufficient. So, what's missing? What would ease the pain most?
>
>
>>
>> Improvements to the XML configuration in this area are on the roadmap:
>> https://github.com/jOOQ/jOOQ/issues/1171
>>
>> Contributions towards such requirements would be welcome, of course.
>>
>
>
--
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/groups/opt_out.
