Let's push the discussion further though.
This comment reminds me that I only store a particular type in a
column, no mixed types, and I found it was a limitation that I could
not say "this column is of Java Object Type X". In a way, I am really
looking for a Custom Type definition and Java Object seems like the
begining of such functionality. If a Class could be attached to the
OTHER column type, then we could specify "Object.class" for the
current behavior, or "City.class", etc.
See:
http://www.h2database.com/html/grammar.html?highlight=domain&search=domain#create_domain
Domain is the sql term for type
That's the concept around which custom types and inheritance should be
built.
Currently the implementation is minimal.
But that's the place where it should be extended if one so desires.
Hacking some few features into one part of the database (namely the
Object/OTHER type) would make H2 more difficult to master.
When defining a type one would need to provide to DBMS the following
- Set of values the type can have (that's essentially how type is defined)
- representation(s) of the type. That is how those values are
represented as literals
- storage of the type. That is how the db should store the value
"physically".
If the DBMS already supports the basic types like "list of characters",
"integers", "list of bytes", boolean etc.
Then all other types can be derived (inherited) from those basic types
using constraints on the set of values of the parent type.
Further some basic functions for a type should be defined like equality,
often ordering related types like < and >.
And finally casting functions that define to which types can this type
be converted.
Autocasting is typical for scripting languages and personally I don't
think it fits well within dbms because it can be the source of hard to
find problems in complex scenarios.
Assume SomeID is a BIGINT.
SELECT * FROM Data WHERE SomeID = '547839'
vs
SELECT * FROM Data WHERE SomeID = CAST('547839' AS BIGINT)
SELECT * FROM Data WHERE CAST(SomeID AS VARCHAR) = '547839'
SELECT * FROM Data WHERE SomeID = CAST('547839' AS VARCHAR)
I think we saved a few keystrokes with the first form. Normal users do
not necessarily understand this level of details. And what they can do
with numbers, they may expect to do with Objects.
Rather than make the dbms undocumented and unpredictable (trying to
guess what the user really wants)
I would rather order the novice database user to learn and understand
the concept of types.
1/ Current message does not tell anything meaningful to normal users.
"Hexadecimal string contains non-hex character" should read "Automatic
conversion to String is not supported, explicitely cast using
CAST(field AS VARCHAR)".
+1
Good documentation/error messages never hurt
- Rami Ojares
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
