directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [DISCUSS] [Release Scheme] Contract/Policy with users for releases
Date Thu, 06 Jan 2011 13:15:49 GMT
On Thu, Jan 6, 2011 at 12:42 PM, Stefan Seelmann <>wrote:

> >>> I would get the Database Format and Configuration out of the equation.
> >>> It's
> >>> up to us to provide tools to migrate from one format to the other.
> Don't
> >>> get
> >>> me wrong : when I say that configuration is out of the equation, I mean
> >>> that
> >>> the configuration can change, not its format (ie switching from XML to
> >>> DIT
> >>> is possible between to major releases, not between two minor releases).
> >>>
> >>>
> >> Will this be transparent to the user? Meaning can he just upgrade the
> >> software and the migration will occur without any change in their
> >> workflow,
> >> or anything noticeable in performance, wait time on startup? More
> >> specifically:
> >>
> >> (1) Does the user have to run a tool to migrate from one version to the
> >> next
> >> ?
> >
> > Definitively, yes.
> I think the database format must be stable between micro (bugfix) and
> minor (feature enhancement) releases. For major releases it is
> acceptable to change the format and to provide a migration tool.

This is exactly what I am trying to get consensus on.  The DB format impacts
compatibility and so it's something we must consider based on our versioning

But with this milestone approach we only have to lock in the format when we
reach the RC stage.

> Please keep in mind that the current JDBM format is not final yet. We
> introduced the RDN index for fast moddn operation, but still have the
> oneLevel, subLevel, and alias indices that are not updated in O(1).

Good point. Yet these indices present a different problem entirely, actually
it's only the subLevel index which is an issue. Quickly without diverting
from this thread's central point let me jot down some immediate thoughts.

History & Background

The DN index that was replaced with an RDN index gave us O(1) moddn
operation speed. By not having to update all DN indices, due to a single RDN
component index entry update we gained the speed (also stability/atomicity)

The same does not apply to subLevel which maps the IDs of ancestors entries
to descendants. The oneLevel index is not a worry (still an O(1) operation)
since a moddn impacting a parent child relationship is a single update.

Remaining Potential Performance Problem

Serious performance problems and issues with atomicity may still result from
the subLevel index with moddn operations since this can impact millions of
index entries.

Unfortunately, unlike the RDN index/DN index technique, we don't have the
same simple solution. Once the ancestor, to descendent relationship is
broken with a moddn, these index entries must be updated.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message