Yes, the forcedType should go a long way towards cleaning up our code. You should probably mention it in the javadoc for DataType, Binding, and Converter. :-)
What did you have in mind? The connection details and schema are provided by the user at runtime so our options are limited but we could set up an empty schema if necessary. Would that generate the standard classes with converters we specify or is it all hidden in schema-specific calls? Or were you thinking of setting a runtime flag? Bear On Mon, Mar 19, 2018 at 9:20 AM, Bear Giles <[email protected]> wrote: > I'll look into it. We can't use code generation so I haven't been > exploring that part of the API. > > (Well, as a mental exercise I wondered what would happen if we took the > customer's SQL, ran it through code generation, ran that through a > compiler, then loaded the new class via a custom classloader. But that's > mostly as an April Fools prank for my boss because I have no trouble > imagining how the PM would respond to that idea. ;-) ) > > Bear > > On Mon, Mar 19, 2018 at 3:08 AM, Lukas Eder <[email protected]> wrote: > >> Hi Bear, >> >> Are you aware of the possibility to apply data type rewriting in the code >> generator, or to apply converters or data type bindings? >> >> - https://www.jooq.org/doc/latest/manual/code-generation/dat >> a-type-rewrites >> - https://www.jooq.org/doc/latest/manual/code-generation/cus >> tom-data-types >> - https://www.jooq.org/doc/latest/manual/code-generation/cus >> tom-data-type-bindings >> >> Note that these things can also be applied even if you're not using a >> code generator. Let me know if you have questions about this. >> >> Further comments inline. >> >> 2018-03-18 21:01 GMT+01:00 The bear in Boulder <[email protected]>: >> >>> I know one possibility is to fork and create new databases like >>> MY_POSTGRES which is identical to POSTGRES except for the >>> org.jooq.util.postgres.PostgresDataType class. >>> >> >> That sounds like a lot of work to get it completely right. >> >> >>> That's a bit annoying since we'll want to reuse the rest of the >>> PostgreSQL-specific code. Could we just overwrite the entries in the >>> DefaultDataType cache instead? >>> >> >> You could, and it might work for some cases, but I'm not going to >> recommend, nor endorse it, as I have no idea what the overall effects of >> such a hack would be. It doesn't sound like a very good idea. >> >> Again I know this is extremely advanced >>> >> >> Not so advanced :) jOOQ has had support for custom data type conversion >> since very early days, and the custom data type binding SPI solves almost >> every custom data type problem we've encountered on this list so far, by >> allowing to override how custom types are bound to JDBC. >> >> The only missing feature as far as I can tell is to allow for binding a >> single client data type to a collection of columns (e.g. a range type to 2 >> columns "from", and "to"). >> >> Hope this helps, >> 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/to >> pic/jooq-user/mVAv6TQfApg/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.
