UUID actually is not just a 16 bytes but it's a type strictly defined
by RFC. The most important it has well defined string representation
to be easily interchangable between different kinds of software. So
higher level of generality you are talking about will lack this
feature.
Ok, good to know.
Maybe something like this could be added to the documentation:
(Copied from wikipedia)
"A UUID is a 16-byte (128-bit) number. The number of theoretically
possible UUIDs is therefore about 3 × 1038. In its canonical form, a
UUID consists of 32 hexadecimal digits, displayed in 5 groups separated
by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32
digits and 4 hyphens).
Example: 550e8400-e29b-41d4-a716-446655440000"
I assume that if someone does not provide all 32 digits and 4 hyphens an
exception is thrown?
Further a byte array of exactly 16 bits must be provided?
I don't remember what the literal representation of a binary is but I am
quessing it is a hexadecimal string.
So UUID is BINARY(16) with the 4 hyphens added to the literal
representation, right?
AFAIK in h2 the only difference between VARCHAR and CHAR that latter
is trimmed from right and actually is not recommended for use because
it can behave differently in other dbms. I think the same thing would
be with VARBINARY/BINARY (in h2 there is no difference at all). So
just use VARCHAR and VARBINARY (or may be BLOB) probably will be good
engineering practice:)
I wonder why CHAR is trimmed from the right...
Oh, never mind :-)
The difference between char and varchar can be described with the
following equivalency
CHAR(16) <=> VARCHAR(16) CHECK LENGTH(VALUE) = 16
Then some databases started to accept shorter strings and padding the
string to the correct length.
(I think they used to mostly pad the strings from right instead of
trimming them from right like H2,
And if the value had more characters than maximum and exception was
thrown..though I might remember wrong).
Fixed length strings are relics in current computer world and now we can
drop them because
if we want to constrain a column to a certain length we can do that with
constraints.
So let's get rid of the char type or rather treat it the same as varchar
with an extra check constraint.
But then why should we keep VARBINARY and BLOB separate?
From user's point of view there is no difference.
The only dilemma this separation is trying to solve is how to deal with
values that are big.
But this could be solved at runtime by the server, setting a maximum
size before the value is streamed to disk and not kept in memory.
Then that same binary could be accessed in jdbc as byte[], InputStream
or Blob object and jdbc api would still be fully satisfied.
- Rami
--
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.
