[Date Prev][Date Next]
> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
> A couple of thoughts (mostly food for thought)...
> This will obviously cause a serialization of directory
> updates within the context and contention on the lastmod
> entry. I think it would be offer a version which didn't
> back the lastmod entry into the database. One could even
> address persistency issues by determining the values from
> the entries at start up, instead of relying on the backing.
> If we had ordering indexing, determination would be quick.
Speaking of which... I never found any order-preserving hash functions that I
could see being generally applicable here, but we could certainly do some
indexing for specific syntaxes that represent timestamps and other limited
size/range values. (I.e., we can crunch their normalized value directly into
a 32 or 64 bit integer losslessly.)
One gotcha here is that we would need to avoid overlapping/clashing with the
current hashed index key space. It kinda implies resurrecting the use of
subdatabases, which may not be a safe thing to do. Thoughts?
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support