Hi,
I'm a bit confused about how to make use of set_dup_compare with
indexes.

To use a concrete example, suppose my primary store is a Person store
where the keys are integer IDs and the
values are serialized Person objects as shown below:

class Person
{
string firstName;
string lastName;
int age;
};

Also, suppose I have a last-name index created using DB::associate
which uses the lastName field as the
secondary key. Further suppose (for argument's sake) that I'd like to
sort duplicates in the last-name index
by using the age field.

My basic question is ... how do I achieve this?

What I have tried is calling

set_dup_compare(dup_compare_fcn_type dup_compare_fcn)

on the index. The problem I have is that I was surprised to find that
the values passed by Berkeley DB to my
dup_compare_fcn are the primary keys rather than the primary values.
At first I thought, "oh, ok, no problem,
I'll just use the primary keys to fetch the corresponding values from
the primary store". I tried that, but
the problem I found is that only one of the supplied primary keys
actually has a corresponding value in the
primary store. This kinda made sense to me as my dup_compare_fcn is
being called during the insertion of
an element into the primary store so that element may not be there
yet. But now I'm a little lost as to how
to achieve my desired goal. I assume I am missing something obvious,
but what?

Any help would be appreciated.

thanks,
mick

In article <a6ae23bc.0308201927.4fae7cf7 (AT) posting (DOT) google.com>,
michael.hollins (AT) silverbrookresearch (DOT) com (Mick Hollins) writes:
Did you apply the dup_compare to the primary DB? I think that you
have to apply it to the secondary DB only. Duplicate keys are not
allowed on the primary DB I don't think. Also, I think you should
check to make sure that the primary DB has duplicate keys disabled.
If there are duplicate keys in the primary DB then there is now way
to systematically determine which one is referenced by the secondary.

/Nathan.

hackett (AT) gardi (DOT) home.rapdat.com (Nathan Hackett) wrote in message news:<Kq2dnRnX6oNl8dmiRVn-jA (AT) speakeasy (DOT) net>...
No

That's what I did

Everything is set up right as far as the index goes.

As my original post said my problem is that:

"I was surprised to find that the values passed by Berkeley DB to my
dup_compare_fcn are the primary keys rather than the primary values"

When I thought about it it kinda made sense to me as a berkeley db
index is
just an ordinary berkeley db file where for each element the key is
the
secondary-key and the value is the primary key from the primary
database.
So in that way it made sense that berkeley db would pass the primary
keys
as the arguments to dup_compare_fcn. It just means, as far as I can
see, that
set_dup_compare is not particularly useful for indexes due to the
problem I described
in my original post (i.e. there is no way to get from the primary keys
to the
primary values).

I have now gone for a completely different solution to my problem
which avoids
the use of set_dup_compare altogether. I am now using an index which
is totally
ordered (i.e. no duplicates) by last-name and then by age so that I
can now use
Dbc::get(DB_SET_RANGE) to position a cursor at a particular last-name
and then use
Dbc::get(DB_NEXT) to iterate over all the people with that last-name
in age order.

Still curious, however, to get a definitive response on whether my
belief is true
that set_dup_compare is not useful with indexes.

thanks,
mick

In article <a6ae23bc.0308220233.6d519f34 (AT) posting (DOT) google.com>,
michael.hollins (AT) silverbrookresearch (DOT) com (Mick Hollins) writes:
The dup_compare whould be useful if you took the other tak and append
the age to the primary key. Then the dup_compare function would have
access to it.

Then you would have to use Dbc::get(DB_SET_RANGE) to get data directly
from the primary. I think your solution is probably better.

Still, dup_compare would generally be useful as long as the information
needed to sort duplicates is all in the primary key.

Also, I am suprised that the primary values are not entered before the
senondaries? That wouuld seem like the logical thing to do, otherwise
there might be some short period of time where there is a secondary in
the database that references a primary key that is not there yet.
Maybe db tries to make updates to the primary atomic
with respect to updates to the secondary, then accessing the primary
from the dup_compare function for the secondary may not be safe?

/Nathan.