[Date Prev][Date Next]
Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
- From: firstname.lastname@example.org
- Date: Tue, 30 Jun 2015 12:52:26 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Hallvard Breien Furuseth wrote:
> On 29/06/15 23:05, email@example.com wrote:
>> Seriously, why aren't we just saying "don't do this" and moving on?
> OK, then document it. Maybe keeping it simple, call
> mixing mainDB data and named DBs a user error and warn this
> can break the DB.
We have already documented this. "Database names are kept as keys in the
unnamed database." It should be obvious that if you muck with the record of an
existing key, things will change, therefore you should not muck with those keys.
>> There are
>> lots of stupid things you can do with software. It's a waste of time and
>> energy to prevent them all.
> We totally disagree, starting with what is stupid. But we knew
> that. That's I asked which parts of "mdb/bundle" to push and
> which you rejected, we must have misunderstood each other. I
> thought I was just ITSing this commit properly before pushing.
I just don't see this happening in practice. Most applications will never use
subDBs. It's not like some random person is going to come along and open an
arbitrary LMDB file created by some other application and start mucking with
it, without knowing the meaning of what's inside. Embedded database libraries
are used in specific contexts by their enclosing application. They don't just
get random ops thrown at them from 3rd party code. The designer of the
enclosing app will design a schema/whatever set of tables to use and that
scheme will be fixed for the life of the application.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/