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
