[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
More on ldbm_initialize in libraries/libldbm/ldbm.c
The home that is passed to ldbm_initialize (from back-ldbm/init.c) is
not yet initialized (ie. points to NULL), and therefore has no effect on
the underlying database calls. However, your new routine,
ldbm_initialize_env, is called later to initialize DB3, with the a
different structure member (li->li_directory) that does contains the
home. This has the unfortunate consequence of breaking the ldbm_open
calls in the tests, because relative directory paths are used in
slapd.conf (but only for DB3 at this time).
It seems that by the time ldbm_initialize is called, lbi->lbi_directory
should be set, but it isn't. Actually, I don't even know why they
bother having an lbi_directory member there -- it makes no sense. At
that point it is not yet time to deal with backend-specific
configurations, and none are available. The easiest fix right now would
be to not set the home at all, although there are certainly advantages
in setting it.
If I gather correctly, ldbm_back_open is the function to initialize the
portion of the backend environment that will be shared by all instances
of a given type of backend (in this case back-ldbm). For back-ldbm, it
allocates a private structure, of type ldbm_backend_info, which has the
member lbi_directory.
Later, the function ldbm_back_db_open(BackendDB *be) has
li->li_directory available, and is initialized. Thinking out loud
here. I'm open to suggestions.
Randy