OK, I'll arrange a vote around suggestion #3, seeing that this is so far the thing that most people seem to like.
2014-05-01 1:32 GMT+02:00 Henry Saputra <[email protected]>: > My take is since we are in incubator let us take advantage of making > breaking API changes. Clients already have to change code to cope with > the new package naming based on Apache. > > I like approach #3, looks cleaner and support pluggability to the > context for different implementation of ColumnType interface. > > - Henry > > On Tue, Mar 25, 2014 at 7:54 AM, Kasper Sørensen > <[email protected]> wrote: > > 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 >
