Data type conversion - JDBC odd types

I have an application which browses databases tables who’s structure is unknown beforehand.

For this reason I cannot use JPA. So I use
and FreeformQuery.

Now I’ve come across some Oracle types that require extra attention, most notably
. For these kind of types there’s no JDBC-standard equivalent, so
would return an Oracle specific Java type, as in
, rather than the classic Java types or any of the
. I wish I would get a Java Date or a Java Calendar, but that’s just not have the Oracle JDBC driver works. I believe the main reason that Oracle JDBC dev has made this design choice is that you would loose the nano-second information because such precision isn’t supported by Java Data or Java Calendar. I could happily do without the nano-seconds.

Normally, I would just use a
Vaadin Converter
for this purpose and then add it to my
I register with my VaadinSession

This is all okay, but in order to convert
object into something useful you actually need the JDBC connection from which you’ve obtained the value. (Look at the
if you don’t believe me. I can make long story about why Oracle has created it this way, but I’ll leave that for another day). Of course when I’m inside my
, I do not have access to the original JDBC connection. The way I see it, is that I actually need to hook into the ResultSet traversal loop.

How can I solve this ?
Please advice. I do not much like to roll my own SQLContainer. :frowning:

This was what came out of it:

Add-on : SQLContainer Enhanced

(also has a few other enhancements in addition the problem mentioned in this post)

Wow, that’s really nice work, thanks for your effort! I’ll have to try it out just for the MariaDB support.


Well, haven’t actually done much on MariaDB in the code itself, other than saying that MariaDB works exactly as MySQL, only the name of the JDBC Driver class differs. In this sense you can say that SQLContainer from Vaadin core has always had
support for MariaDB, it just wasn’t advertised. Now the support is explicit.

In fact SQLContainer may support more databases than what it currently advertises. For any new database (say IBM DB2) you would have to analyze if the SQL dialect of that database fits with some of the existing implementations in SQLContainer, and if it does then you are already there. (DB2 is probably a bad example because it will for sure require a little bit of tweaking to add support for it).