On Thu, Jan 6, 2011 at 12:42 PM, Stefan Seelmann <seelm...@apache.org>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 scheme. 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) advantage. 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 :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
