I think that rather than use a join, you should set up the b-tree
expressing the function as a secondary index. see:
http://www.sleepycat.com/docs/ref/am/second.html
http://www.sleepycat.com/docs/api_cxx/db_associate.html

If there is some other criteria that you need to check in addition,
that has a different index, then you would use the join functionality.

You can set up the callback function to calculate the expression
and store the result in the secondary index. It would be best to
define your own comparison function as the default is to do a byte
wise comparison, which will work on some architectures but not
others.

Michael Ubell
Sleepycat Software.

Michael Ubell <ubell (AT) sleepycat (DOT) com> wrote

was trying to accomplish. Here it is.

I have a set of objects in a queue, each object represents information
about a site (each site can have many such objects). There are two
b-tree indexes to those objects, both of which reference queue ids.
One index is of site ids, the other is essentially a version counter.
I want to count the number of objects with a particular site id that
have a version number > than a particular number, where the particular
number can vary by query. So I need join functionality, but not a
normal equality join.

The b-tree containing version numbers was created with a special
comparision function, to sort numerically by version number. But a
normal join using these indexes against the queue only returns exact
matches with the version number. Even when I initialize the cursor for
the version index with DB_SET_RANGE it does this.

Do I need to re-create the join functionality for non-equality joins?
Or am I doing something boneheaded (more likely).

Thanks,

Mark

Mark Fletcher wrote:

The join functionality only supports equality, sorry. You will have to
impliment the functionality yourself, I think.

Michael Ubell
Sleepycat Software.