Mike Matrigali wrote:
See comments below, once updated I will work on getting it into the
codeline.
Comments on unique key handling.
From one perspective the current btree implementation assumes all rows
it handles are unique. This is because the row includes the the last
column which is the address of the base table row. One could not use
the current btree implementation to store 2 rows which were exactly
the same including the row location. At this level having all rows
being unique makes the code simpler as binary searches don't have to
worry about edge cases of duplicate keys.
Having said that the btree implementation does support rejecting rows
which are not unique given a subset of the columns of the row.
Currently this is only used to compare whether index rows are unique
comparing all columns other than the last one. So to create a unique
SAL index you create a btree telling it to enforce uniqueness on
number of columns - 1; and to create a non-unique SQL index you create a
btree telling it to enforce uniqueness on all columns.
Mike,
I assume you mean that at the leaf level, no two IndexRows can contain
the same set of keys
and also the RowLocation. I assume my understanding is correct that
BranchRows do not
contain the RowLocation.
I will send you an updated html - do you want the links in Javadoc format?
Thanks
Dibyendu
