Hello

My application does not know the kind of file which the user asks it
to open.

With the Db.DB_UNKNOWN flag and the db.get_type() method, it is easy
to know the underlying kind of database: DB_BTREE, DB_RECNO, DB_QUEUE
or DB_HASH.


But I am wondering how to know if DB_BTREE file is an primary btree or
a secondary btree file??? The documentation of Db.open() and
Db.get_type() specifies only these 4 values and it would help to know
as soon as possible the underlying type of the btree database.


Regards


Francis ANDRE

francis.andre (AT) easynet (DOT) fr (Francis ANDRE) writes:

Hmm. With "secondary btree file", do you mean a secondary index
as in using ->associate()?

If yes, as far as I know, the "secondary" file is a database like
any other, and it is solely the application calling ->associate()
which relates it to another file, dynamically, at runtime. I would
not expect any marker to be present in the file.

In short: with Berkeley DB your application is supposed to know what
it is doing.

Maybe I misunderstood, and maybe my expectation in the second
paragraph is misguided. I'll appreciate being corrected.

best regards
Patrick

Patrick
that an application knows what it is doing....

But that not the case for MY application, not due to my implementation
but due to the specification.
The application is given by a user a primary file name and a secondary
file name as parameters. If the user does not make any error
(sometimes, that's true), there is no problem....But, according the
principle of "defensive programming", my application should control
that the primary file name is really a primary BTree and that the
secondary file name points to a "real" secondary BTree. And for now,
there no I/F provided by BerkeleyDB to check this point since both of
primary and secondary return only the Db.DB_BTREE type.

Nevertheless, BerkeleyDB does know that a BTree file is a secondary
since you got an exception if you insert a record in a secondary.

In my application, I could have up to 253 secondaries for the same
primary and I would like much more to have a imperative way to check
all of them than a try/catch block.

Regards

FA

Francis,

Since your application must impliment the call back function to
associate the secondary index with the primary how does the user
specify this to the application? It seems that the user
needs to specify a significant amount of information properly
to your application. It would be hard to verify that the
call back function specified is the proper one.

I think it would be more reliable if your program genenerated
a description file of some sort that described the relationship
among the databases and have the user pass the name of that
file rather than the names of up to 253 secondaries.

BerkeleyDB only knows this in the context of a running program that
has called db->associate on the database. There is no information in
the file.

Michael Ubell
Sleepycat Software.

Michael Ubell <ubell (AT) sleepycat (DOT) com> writes:

That's what I thought, too. A verification, as far as I can see,
could only be done by making a full pass over the databases in
question, and running the hypothetically correct key mapping
function by hand at each step, comparing results.

I'm actually doing something like that, rarely, from cronjobs,
by dumping the whole database once via the primary, and once
via the secondary key; the output both cases is then sorted
by primary key (i.e. brought into canonical order), and finally
I do an md5 checksum over the two sorted outputs; when the checksum
differs something is amiss.

Such a description could even be a separate meta-database,
or, one could possibly use the "multiple DBs in one file"
feature of Berkeley DB to put one such meta-information
blob into each individual database file. That would be
done once when each database is created, and later the
open-again code can use it to make more consistency checks.

In my real application, where I have one secondary per primary,
but many such pairs, I have already put primary and secondary
into a shared underlying file. That keeps them together pretty fine.

Good to have that suspicion confirmed.

best regards
Patrick