[DISCUSS] further details added to ColumnType

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

In MetaModel every column has a ColumnType (e.g. VARCHAR, INTEGER,
TIMESTAMP, MAP, LIST etc.) which is modelled as an enum. This ColumnType is
retrieved using Column.getType().

FYI some further information about the type is available also [1], for
instance:
Column.isNullable(): Boolean
Column.getSize(): Integer
Column.getNativeType(): String
Column.isPrimaryKey(): Boolean
Column.isIndexed(): Boolean

But sometimes additional information could/should be added about the column
type, such as decimal digits [2] or a richer description about nested
contents if the type is a LIST or a MAP [3]. The trick is that it depends
on the column type.

We can add this in a couple of ways I guess...

For instance, we can do like we did with Column.getSize() and simply expose
these extra pieces of metadata directly on the Column interface. I think
this has the drawback that when we add such type-specific methods to a
general interface, they're not as applicable. On the other hand they could
simply return null to indicate the non-applicability.

We could also change the ColumnType enum into an interface. Then the
implementations of this interface could have additional methods, not
exposed by the interface. The implementations could be either singletons
(for instance a TIMESTAMP singleton) or individual instances (for instance
a NUMERIC instance with decimal digits). The troubls is that this would
break backwards compatibility in the sense that you could no longer use
enum-style comparisons and switch statements with ColumnType values.

Maybe there's more ways to enhance this part of the API that I did not
think about?

What do you think? I think this could be an important change to make to
emphasize and reinforce the metadata aspect of MetaModel. Would it be
worthwhile pursuing, while breaking backwards compatibility?

[1]
http://metamodel.eobjects.org/apidocs/org/eobjects/metamodel/schema/Column.html
[2] Ticket on the old trac system: http://eobjects.org/trac/ticket/379
[3] Ticket on the old trac system: http://eobjects.org/trac/ticket/1157