Hi Sergi,
> As I wrote you can write your query as
> select * from data where cast(object as varchar) = 'bla'
Yes I know, but what I am looking for is a compelling argument. My logic is:
- String to Object is inherently not possible.
- Object to String is possible.
- Why does H2 try to convert String to Object and not vice versa?
> Also at some point
> conversion rules may change so that H2 will not try to parse hexadecimal
> string but just return String object (and for other types such as int,
> bigint, etc.. the same behavior, e.g. return Integer, Long) because I think
> current behavior with hexadecimal is meaningless in almost all cases.
Yes, I fully agree: I don't see where that would mean anything. But
returning the object directly does not tell how to adapt types when
types are not compatible (see below).
> Then
> your logic will be inconsistent because if one stores in the same column
> String '123' and Long 123 and tries to find only String '123' query will
> return Long as well while if one will try to find Long 123 query will return
> only Long.
Ah, at last! A good argument :)
This could be a problem indeed, but I wonder if in practice people
would use simple Java types as mixed content in an OTHER column. In
any case, I think I now have a good case for suggesting the change of
behavior from our fork at work to use explicit cast.
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.
Maybe such definition could go as far as being able to define a
TypeConverter. Not only could we compare Strings to Objects, but we
could potentially compare numbers, etc.
> Good software design is about having as little special cases as
> possible.
Highest order between String and Object is subjective, saying it is a
special case is arguable. In fact, Java Object is a special case, most
database engines do not have them.
> And all you trying to win here is just few keystrokes.
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.
So, to sum up, we are down to 2 issues here:
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)".
2/ Whether there should be a mechanism to convert types.
I don't really care about 2/ for my cases, but maybe 1/ could be improved.
Cheers,
-Christopher
--
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.
