Hi all, I just came across a potential issue in MetaModel's design and want to share it and maybe start thinking of ways to fix or work around it...
In our ColumnType enum we have the method getJavaEquivalentClass() which is used to tell which java type to expect when querying a particular column. For instance, of I query a VARCHAR column, I can expect a java.lang.String value. Now the trouble is that in our JDBC module we have a system property which allows for eager loading of BLOBs and CLOBs so that they are automatically read into byte-arrays and Strings respectively. This is a great utility because otherwise the user has to do a lot of tedious work with inputstreams etc which in most cases isn't particularly useful - in most cases you just want the byte[ ] or String. Now the trouble is that if you turn that system property on, you get Strings or byte-arrays but the column type is still CLOB/BLOB and that means that the "expected equivalent Java class" is still java.sql.Clob or java.sql.Blob! If you build your code to expect that, then it will eventually break because you get a String or a byte-array instead. How to make this consistent? I can think of a few ways, but none that I really love: 1) Probably the easiest way to do it is to let the JDBC datacontext give the columns other ColumnTypes. But that sorta doesn't feel good now that the "real" datatype is CLOB, that we will then call it e.g. VARCHAR. 2) We can remove the getEquivalentJavaClass() from ColumnType and instead make it a direct member of the Column class. This will break backwards compatibility of the API. 3) We can make ColumnType an interface or class instead of a enum. Then the behaviour can simply be plugged in by the JDBC DataContext. I do like this approach the best for many reasons, but it has the downside that it also breaks backwards compatibility of the API and that there will no longer be an enumerable and finite list of ColumnTypes. Maybe we could alleviate that problem by ALSO having an enum with the typical implementations or something like that. Maybe there are other solutions that I didn't think of. Regards, Kasper
