Hmm, I guess it would make sense to review those manual sections and provide XML / programmatic examples for each individual flag... I've registered an issue for this: https://github.com/jOOQ/jOOQ/issues/3930
In the mean time, the simple mental mapping model is this: We're using JAXB and XJC to map from the configuration spec ( http://www.jooq.org/xsd/jooq-codegen-3.5.0.xsd) to XML and/or Java. Thus, there isn't a lot of magic involved. Hope this helps, Cheers, Lukas 2015-01-09 18:15 GMT+01:00 Robert DiFalco <[email protected]>: > Thanks Lukas, this makes a lot of sense. However, I could not find from > the examples how to specify type conversion for Code Generation > programmatically. Currently I am using the approach specified in the Link > you provided, just couldn't figure out how to add the converters into the > Configuration class. > > On Thursday, January 8, 2015 at 10:38:12 PM UTC-8, Lukas Eder wrote: > >> >> >> 2015-01-08 18:57 GMT+01:00 Robert DiFalco <[email protected]>: >> >>> I'm hoping the community can help me better understand type converters >>> so that I can more efficiently (and simply) use JOOQ. >>> >>> It would be GREAT to have a document that provides an overview of all >>> the places where type conversion takes place and how to customize each one >>> -- maybe there is a blog post I could pointed to? >>> >> >> Well, conversion pretty much takes place everywhere where types don't >> match. You will not encounter a ClassCastException easily with jOOQ... >> A blog post (or better, a manual section about auto-conversion) is >> definitely a good idea. We'll think of something to write up when we >> implement ConverterProvider: >> https://github.com/jOOQ/jOOQ/issues/3896 >> >> ... which will be yet another way of providing converters. In fact, this >> goes as far as thinking about externalising conversion logic into a new >> project, e.g. jOOConv, which can convert almost anything. >> >> Here's what I'm seeing: >>> 1. In code generation using a regex to target a field. >>> 2. In configuration. >>> 3. In record.getValue >>> >>> It seems like #3 is probably the least optimal place to have it since >>> JOOQ will do one conversion from the ResultSet using the fields binding and >>> then another from the field's binding to the specified converter. >>> >> >> Yes, those are some places. #3 is not something you need every day, but >> sometimes those local conversions are just very useful. Also, often, you >> don't know the type, because you only have a field name. This is mostly the >> case when you're using plain SQL (http://www.jooq.org/doc/ >> latest/manual/sql-building/plain-sql/) or if you're not using the code >> generator at all (http://www.jooq.org/doc/latest/manual/getting-started/ >> use-cases/jooq-as-a-standalone-sql-builder/) >> >> What other places am I missing, I'm specifically interested in conversion >>> FROM a ResultSet. >>> >> >> What do you mean by "from a ResultSet"? >> >> >>> Is there a programmatic way to changing the binding of a field as it is >>> added to a SELECT statement? >>> >> >> You cannot change the Binding of a Field, but you can create a new Field >> with a different binding. For this, you can use the same API as the one >> used by the generated code. So far, we haven't intended for this use-case >> to be applied in client code, so the API might be a bit quirky / >> internalish. >> >> For example, if I add a CASE statement that I want to return a specific >>> Enum, is my only choice to have the CASE be an Integer or String and then >>> use a converter when record#getValue in my mapper? >>> >> >> The CASE expression returns whatever type you pass in the THEN clause. >> >> For some reason #1 scares me. For example, I could have many fields that >>> are INT and I want to be represented as a Long in java, but some fields I >>> still want to be Integer in java. I don't want to recreated my schema in an >>> XML file. >>> >> >> If your SQL representation doesn't match your Java representation, there >> is *some* form in which you have to express the mismatch. In a previous >> mail, you've excluded the possibility of using the DefaultRecordMapper, >> which does automatic conversion via Convert.ConvertAll when you call >> Record.into(Class)... So, I currently don't see any other options than: >> >> - Use reflection for full automation (e.g. via DefaultRecordMapper) >> - Use a regex to explain exactly where the type mismatch is, and attach >> the type information to the generated code >> - Manually apply conversion via getValue(Field, Class), or other API. >> >> >>> Also, can I specify these programmatically or do I need to do it in XML? >>> Would that be #2? >>> >> >> You can: >> http://www.jooq.org/doc/latest/manual/code-generation/ >> codegen-programmatic/ >> >> Yes. >> >> >>> As a newbie the problem I'm having is that there are SO many ways to do >>> things in JOOQ that it is a little daunting to make choices. :) >>> >> >> Well, you're not the typical newbie. You're already delving into all >> sorts of internals to create a framework on top of jOOQ. As much as we hope >> that we've created an API that is extremely easy to consume, it is probably >> not so easy to extend. >> >> But as I said, that's good (for us). We're constantly deriving new >> use-cases from such situations. >> > -- > 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.
