Code gen with customized field implementation

[Gang Luo]

Hi folks,

The default java generator will generate class file for a table with fields looks like the following

public final TableField<RECORD, Type> FOO = createField(...)

I would like to have a my customized implementation for the field FOO like 

public final Field<RECORD, Type> FOO = createCustomizedField(...)

The current method for table in the default java generator has 900 lines and it doesn't seem good idea to override just to change one line. Is there any trick that will allow me to generate the table with customized field?

Thanks

-Gang

[Lukas Eder]

Hi Gang,

There's no such trick right now, apart from patching the code generator, or post-processing the generated code. In your case, this might be doable using a simple regex replacement.

What's the use-case of doing this? Typically, discussing the underlying use-case proves to be more fruitful than discussing the attempted workaround...

Thanks,

Lukas

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/4d4c0312-f8de-4776-babd-ac4351b0082dn%40googlegroups.com.

[Gang Luo]

Hi Lukas,

Thanks, as always, for your timely and helpful response. Yeah I think post-processing may be the most practical way of doing it.

This is related to the dynamic schema mapping I raised a while ago. We want to capture the value set on the field "FOO" so we can dynamically map the schema to a target schema "TARGET_XXX" where that XXX originates from the value set to "FOO". The reason we try to do it at JOOQ level rather than in the application level (i.e. in addition to set foo value in the query, also set it to some global registry) is to avoid large refactoring of existing application code. An alternative we considered is to register new listener with callback when execution start so we have access to the Query object inside the ExecuteContext passed into the callback. But the condition (provider) inside is not public, and I don't really want to text-process the sql statement in string format which could be tedious and low-performing. Given that, we would prefer to inject our own field implementation for just FOO inside the table so we can capture the value when set. 

Thanks

-Gang

[Lukas Eder]

Thanks for the explanations, Gang. Interesting use-case, indeed - I think I remember your previous emails now.

Starting from jOOQ 3.16, the schema mapping feature will be retrofitted to work based on the new query object model transformation capabilities. Those will be much more powerful and allow for replacing identifiers based on more complex logic than simple regular expressions, see:

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

But I agree, for the time being, your approach seems reasonable, knowing there will be some caveats, including that depending on what you do in createCustomizedField(), you won't be getting your customized field from methods like Table.fields(), etc.

To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/37c89b6e-4df3-49ed-a7df-4d72142f8adfn%40googlegroups.com.