2013/4/8 Durchholz, Joachim <[email protected]>: >> 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.
Precisely. User contributions aren't possible with enums (except for pull requests, of course). > 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. Yes, that's what I had in mind. > Another approach: > - provide functions for the various standard cases in SQLDialect That would be the wrong place to implement these things, in my opinion. > - subclasses can invoke the appropriate functions as appropriate for the > dialect they implement I'd like to keep relevant knowledge close to the consumer. E.g. when a QueryPart binds variables (e.g. org.jooq.impl.Val), then it should know about "appropriate functions". This design worked very well so far. Cheers 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
