metamodel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasper Sørensen <i.am.kasper.soren...@gmail.com>
Subject [VOTE] Change type of ColumnType to be interface instead of enum
Date Fri, 02 May 2014 09:02:17 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message