> This makes me think whether the current SQLDialect
> model is accurate enough, or whether jOOQ should
> eventually migrate to a "feature set model", where
> a SQLDialect is just a bunch of default values for
> all possible feature flags. Example feature flags:
>
> - supports-udts={ no | postgres | jdbc }
> - supports-arrays={ no | oracle | jdbc }
> - supports-procedures={ no ... }
>
> Any feedback to this idea from the group?
If these are enums, that's closing the set of implementations that Jooq can
handle.
If that is to be extensible, you'd need a separate Strategy object for each
choice. I.e. something like
UdtSupport udtSupport;
and subclasses UdtSupportPostgres, UdtSupportJdbc, etc.
The downside is that the different strategy objects would need extra wiring to
access cross-issue knowledge about the driver.
Another approach:
- provide functions for the various standard cases in SQLDialect
- subclasses can invoke the appropriate functions as appropriate for the
dialect they implement
Just tossing around ideas around the issue, I don't have any particular
preferences.
--
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.
