Re: [DISCUSS] Concern regarding ColumnType.getJavaEquivalentClass()

[Henry Saputra <he...@gmail.com>]

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
<i....@gmail.com> 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

Re: [DISCUSS] Concern regarding ColumnType.getJavaEquivalentClass()

[Kasper Sørensen <i....@gmail.com>]

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 <he...@gmail.com>:

> 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
> <i....@gmail.com> 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
>