Scott McCaskill wrote:
> I've been experimenting with using the sqlite3Btree* functions by themselves.
> I'd like to have sqlite3BtreeMoveto use the comparison function (instead of
> an int key), but I see from looking at the code that it never does this for
> pages marked as INTKEY. What causes pages to be marked this way? Also, is
> it possible to have duplicate keys when using these functions? Any other
> suggestions for using these functions would also be appreciated.
>
Each b-tree has three boolean attributes:
INTKEY: True if the key is always a 64-bit integer. False if
the key can be arbitrary length structure that is compared
using a user-supplied comparison function.
ZERODATA: True if the tree holds keys only and no data. False if
there is data associated with each key.
LEAFDATA: True if all data is stored in the leaves of the trees.
False if data is stored on every node. LEAFDATA is
meaningless if ZERODATA is true.
In the current SQLite implementation, tables are implemented
as INTKEY+LEAFDATA. Indices are implemented as ZERODATA. The
btree.c implementation supports 4 other combinations:
(nil)
LEAFDATA
INTKEY
INTKEY+ZERODATA
The INTKEY mode used to work, because that is what was used in
an early prototype of SQLite version 3, before LEAFDATA was
added. But I don't know if it still works. The other combinations
have never been tested, as far as I know.
These flags are set using the "flags" parameter (the 3rd parameter)
to sqlite3BtreeCreateTable().
It sounds like you are wanting to use modes (nil) or LEAFDATA.
If you can get them to work, fine. But remember, they've never
been tested before. And also remember that because these are
not official APIs, no promises are made about whether or not
they will continue to work in future releases.
The implementation in btree.c always requires all keys to be
unique within a single table. If you try to insert a new entry
with the same key as an existing entry, the existing entry is
overwritten.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
