Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
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 SQLContainer and FreeformQuery.
Now I've come across some Oracle types that require extra attention, most notably TIMESTAMPTZ. For these kind of types there's no JDBC-standard equivalent, so ResultSet.getObject() would return an Oracle specific Java type, as in TIMESTAMPTZ, rather than the classic Java types or any of the java.sql.types. 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.
This is all okay, but in order to convert TIMESTAMPTZ object into something useful you actually need the JDBC connection from which you've obtained the value. (Look at the Javadoc 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 Converter, 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. :-(
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 implicit 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).