- We always create an environment. If we dont have permissions to create
or join a shared environment, we use a private environment. Instead
of trying to figure out what to do beforehand, retry dbenv->open()
with different flags to see if it succeeds. This eliminates some
potential races when others might create/remove the environment
while we're pondering about appropriate flags.
- Lose the "create" bdb config option, this is something we always
want to decide internally.
- Remove "force" bdb config option, DB_FORCE is dbenv->remove() option
and its value clashes with DB_CREATE...
- lose the hysterical dbi_use_env condition and usedbenv option
this is always enabled
- ensure mpool is always initialized, lose the config option (this
is a mandatory BDB subsystem, not a bleeping configurable)
- let pagesize be what it is even when no configuration is present
- avoid overriding dbi_mmapsize and dbi_cachesize if set in the configuratio
- these are all per-environment, not per-dbi settings but for now...
- we never want DB_CREATE to cause failure - let BDB create the
db if it needs to, otherwise DB_CREATE doesn't do anything
- rdonly is decided elsewhere, not in bleeping configuration
- transactions aren't currently used, we'll need txnid handles eventually
but the dbi is unlikely to be the right level to store this, add
where actually needed when the time comes
- The "was this verified already" bitmap uses header instance numbers
which are monotonically increasing and can be much much larger than
the number of actually installed headers. Grab the current instance
number for a better idea how much we'll at least need.
- Throw out the db stats based dbiNumKeys(), this doesn't have the
kind of performance penalty that stats have and suits our purposes
better anyway
- all additions and removals to the rpmdb need to go through the
transaction machinery, these are very low-level functions that
API users have no business messing with
- not perhaps the ideal place for it but the backend level needs
access to the main db in several places anyway, and this leaves
rpmdb_internal.h clear for internal-only APIs
- rpmdbRemove() takes now a header as argument too - we need both
the header number and the header itself there anyway, so might as
well use the header we already have instead of flipping through backwards
hoops to get to it
- for rpmdbRemove() these have been completely unused, and for rpmdbAdd()
the higher levels have had more than one chance of verifying the
header if checking is enabled in the transaction set
- avoid allocating header instance for something that we'd fail to add
- avoid possibly adding data to indexes even if adding the header
itself fails, duh
- This fetches the special key zero which is used for bookkeeping of
header "instance" numbers, the actual header to be stored is NOT
relevant here
- keyp, keylen, datap and datalen are just redundant fluff, manipulate
the key and data DBT directly
- As RPMDBI_PACKAGES is always the first index, the for-loop never
did anything else than open the Packages db and exit with success/fail.
For the same reason RPMDB_FLAG_MINIMAL didn't do anything at all here,
lose the unnecessary flag..
- Turn dbiStat() into more useful: return the number of keys in the
index, hiding away the BDB internal access method stuff into the backend
- Force statistics gathering at Packages db close, take advantage of
that when its opened to get a fairly accurate count of packages for
initial "header verified" bitmap allocation. Previously DB_FAST_STAT
was used on open but it never returns anything when no stats have
been previously collected, hence the need for the expensive slow stat.
- The performance hit from stat generation is hardly worth it for
the bitmap allocation alone, but lets see if there are other uses...
- Also gets rid of dbi_stats member, this is not particularly useful
- dbiOpen() in rpmdb.c operates on "rpmdb layer" so calling it
rpmdbOpenIndex(), dbiOpenDB() on the other hand is the lowest level
backend thing, which is now called dbiOpen() to be in line with
the other operations like dbiClose()
- the backend doesn't care about the tag beyond initialization,
and the tag is only used for error messages from rpmdb layer which
already knows what the tag is
- the dbi presents an internal api of its own, and deserves a separate
header (baby steps to making dbiIndex opaque outside the backend)
- move dbiVerify() to the backend where it belongs
- mark all the dbiFoo() functions as internal
Panu Matilainen