OK, lets proceed on this... I'm going to update my patch to match the current master and push. Den 02/05/2014 14.10 skrev "Ankit Kumar" <[email protected]>:
> +1 agreed as well in the discussion thread. > > I guess this helps clients of MM to work with more common Java types > (String and Objects) rather than worry on sql types. > > Regards > Ankit > > > On Fri, May 2, 2014 at 11:02 AM, Kasper Sørensen < > [email protected]> wrote: > > > Hi all, > > > > I'd like to call for a vote to accept proposal #3 mentioned in the thread > > "[DISCUSS] Concern regarding ColumnType.getJavaEquivalentClass()". The > > proposal is to change the ColumnType enum into an interface. > > > > There is a patch to implement the change here: > > https://reviews.apache.org/r/20028/ (as you can see the impact is pretty > > wide). > > > > To make some pros and cons clear, I'll try to list them based on the > > [DISCUSS] thread: > > > > Pros: > > > > * New ColumnTypes can be plugged in easily. > > * Variants of the same "native" column type can be provided. The example > > in the [DISCUSS] thread is about CLOB and BLOB types - whether or not to > > represent them as Strings vs. java.sql.Clob etc. > > * More information can be added to a particular ColumnType without it > > leaking into the interface of all other ColumnTypes. For instance > > number-types could have an "isDecimal()" method etc. (METAMODEL-8) > > * The list of ColumnTypes would no longer have to be JDBC inspired. For > > instance: With CSV files we currently use the VARCHAR column type, while > a > > more generic "String" or "Text" column type would be semantically less > > misleading. > > > > Cons: > > > > * Backwards compatible deserialization would not work (yet - maybe we > can > > find a way in the LegacyDeserializationObjectInputStream class). > > * You can no longer use switch-statement with ColumnTypes. > > * It would no longer be possible to enumerate all possible column types. > > > > I will kick off the VOTE and give my vote for the proposal: > > > > +1 > > >
