The original question ultimately boils down to whether the author
wants to keep H2 a "true & pure DBMS", or allow adding some goodies
that are handy in some situations.
I don't think the issue is best captured by setting against each other
some obscure ideology of
truth and purity with the style of handy and dandy goodies.
I think the issue is how clearly some specific program is defined.
We all know that most of the programs we write is meant for one
particular use case.
And then we keep adding features as the need arises.
But when we try to construct a software that is meant to be used for
some specific purpose by all kinds of software,
then defining features in a manner that is logical and coherent makes it
1) easier to implement because the implementation flows from well
thought out concepts
2) more free from bugs because the lack of endless combinations of
corner cases
3) simpler to document because the concepts have been well defined from
the outset
and because the lack of corner cases.
The best of both worlds can be achieved if the tool/program has a clear
extension mechanism.
In case of dbms these mechanisms include user defined types, functions
and triggers.
Then all kinds of handy and dandy features could be shared by the community
but would not give headache to the core definitions of the dbms.
Currently from these three extension mechanisms H2 is lacking only a
good model of user defined types
(I have argued before that the implementation of domain is still rather
weak).
But before implementing User Defined Types (domains) it would be
beneficial to have a clear
definition of what type means in H2.
Let me give an example:
- Type defines a set of values.
- A variable that has that type must have a single value from that set
of values.
- Type needs to define a literal representation for all those values so
that a literal always picks
out exactly one of the values from that set.
- Type needs a storage representation that the normal dbms user does not
need to know anything about
but a type definer must define it - if only implicitly.
Type can have operators defined.
The most important out of these operators is the equality operator.
If a type does not have one defined it can not be used in a key
(uniqueness not defined).
It also can not be used in expression like A = B.
So even though the equality operator is not strictly needed without it
the type is obviously quite crippled.
Composite types (types that are composed of many parts that are supposed
to be visible to the user)
have one basic deficiency.
Example:
Let's define a type
Point(INT x, INT y).
Then let's have 2 variables of that type:
a = Point(2, 4)
b = Point(1, 3)
The equality operator would be defined so that it returns true if a.x =
b.x and a.y = b.y
One would need to define a component extractor operator (here .x and .y)
in order to make queries regarding x and y coordinates.
That's all fine but it is just more work than putting the data into two
int columns.
However if the user's interest concerns properties of the point say
distance from origin,
then it is well-grounded to define type Point.
WHERE DIST_FROM_ORIGIN(a) > DIST_FROM_ORIGIN(b)
From the point of these definitions I think that OTHER and ARRAY are
not very well defined.
Currently OTHER does not seem to differ much from BINARY type.
What you were asking was that equality operator would be defined for it.
I would quess that now the equality is determined the same way as for
BINARY type - that is comparing all the bytes with each other.
Now let's consider the implementation.
How are binary type values searched from the database file?
I don't know, but I quess that one needs to read them all into memory
and start comparing.
How could this be sped up with an index?
Maybe putting the first N bytes in some order and using binary search on
that index, then loading only those
binary values that matched and finally throwing away those that did not
match after all.
Obviously this strategy would fail if files of certain kind always start
with the same kind of byte sequence.
If we would define the equality operator for the OTHER type based on
it's equals(obj) method then how would we define the index?
If we don't define the index then to search all equal values would
require us not only to load the bytes
into memory but also to instantiate all those objects.
So clearly we would need that the object would also have a method
someting like long getIndexValue()
that would also define an ordering in the type so we could find equal
objects a bit faster.
All in all my point is that I am not advocating some fanaticism towards
purity & truth.
I am advocating good engineering practices.
- Rami
Ps. Also I would criticize IDENTITY type because it is not a type but a
shorthand to define a type (BIGINT) and a sequence with one word.
Also UUID is a bit odd. It is said to be 128 bits (16 bytes = 2*bigint)
long.
So it could be more generically expressed as BINARY(16) (also a
distinction between BINARY and VARBINARY should be made here).
Actually it is not clear from the documentation if 16 bytes is the upper
limit or if all values are 16 bytes.
Also it is not said how the missing bytes are padded (probably padding
is added to left with 0 bits).
Also when a String is converted to bytes if the jvm encoding is UTF-8 it
could produce uneven number of bytes but maybe this is taken care of
with padding.
Equality is obviously based on binary comparison.
But wouldn't it have been a more generic strategy to define 2 type
generators
BINARY(bytes)
VARBINARY(bytes)
These are simple for everyone to understand because the same idea has
been implemented for strings.
And what's nice with this strategy is that it is compatible with SQL and
JDBC!!! :-)
--
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.
