+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 >
