Hello,

> I like the idea to have annotations which tell you what you can use and what
> you can't. As an additional layer of safety, it would be great if I could
> install a dialect "monitor" which throws exceptions when I call these
> functions (the error messages will probably be better than the SYNTAX ERROR
> that you will get from the database - especially in the case of Oracle which
> frowns upon helpful error messages).

Yes, that mechanism exists, in principle, through
org.jooq.exception.SQLDialectNotSupportedException. It is not applied
thoroughly throughout jOOQ though. What troubles me is the fact that
the exception is usually thrown at place quite remote from the actual
API method...

> I think marking the methods deprecated works but I don't like to "abuse" an
> existing annotation for a new case.

Yes, it's not the perfect solution. But it's the only annotation that
I know of that has an impact on all compilers.

> Unfortunately, adding project specific
> annotations to the Java compiler isn't as easy as it might be. Maybe
> consider to have a look at Project Lombok for some ideas what is possible
> and how "abusive" it is.

I've had a look before. I'd like to avoid going too far into compiler
/ bytecode manipulation.

> As for generating the code with a Maven plugin: Instead of processing the
> jOOQ source code itself, wouldn't it be better to annotate/modify the
> generated table/model code? So that I can only see the methods which are
> available for the databases that I want to support?

I'm not sure if I understand this...? Could you provide an example?

Cheers
Lukas

Reply via email to