>> More seriously, since Jooq's mission is "database first", >> JDBC conventions are probably not an authoritative source >> for DB encoding conventions. > > I trust that the JDBC specification was made by an expert > group based on well-informed "database-first" decisions.
Given the large number of project for "a better JDBC" (including Jooq), I'd say those people were better database than Java experts. And this is an interface issue: how to interpret attempts to retrieve a Boolean from a field that isn't boolean on the database side. > In particular, this case is not a convention but behaviour > by specification. JDBC drivers are to adhere to this > specification. I doubt that any driver fully implements any JDBC spec. (ojdbc doesn't anway.) Still people have to work with them, so the spec isn't the final word on this kind of issue. > Hence the abstraction provided by JDBC over any underlying > database is trustworthy enough for jOOQ to rely on - unless > there is some specification ambiguity that I have now > overlooked...? It's JDBC's take on what to do if trying to retrieve a Boolean where the database delivers something non-Boolean. That doesn't mean that it should be used by default. I wouldn't want to, for various reasons (I like to have representation nailed down, and I'd expect more drivers to have forgotten to implement this special conversion rule, particularly if the database does have a boolean type, so if cross-database portability is an issue I'd want to short-circuit this potential source of bugs from the outset). That said, of course I could just nail down everything using a converter, so it's not a showstopper either way :-) Regards, Jo -- 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.
