directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [apacheds] Idea on refactoring Database, ContextPartition, and RootNexus
Date Sun, 19 Jun 2005 06:45:19 GMT
2005/6/19, Alex Karasulu <>:
> >* Put (used to add and replace entries)
> >* Remove (used to delete entries)
> Right but we may need to carry some information specific to the type of
> operation being performed.  A few people commented on needing this
> feature but I guess we can treat it separately since its not there now
> :-).

What kine of extra information?

> >2) Let's remove ContextPartition
> You're removing context partition totally?  The following JIRA issue
> here re: nested nexus' will be done using DatabaseNexus objects instead?

Yes, DatabaseNexus will have mount and unmount (or
register/deregister) methods so that we can mount Database
implementations to specific DN.

> Also these changes will not break alias dereferencing I hope as its
> documented here:

Is this rule programmed somewhere in ApacheDS?  Which class?

> I like what you've done here but how about calling Database a context
> partition.  In LDAP a context maps to an entry in the DIT and your
> Database will do that too.  Leave the RootNexus as you planned below
> with its new functionality.  Create a new ContextPartitionNexus and make
> it concrete to replace the DatabaseNexus.  So basically we are creating
> another layer of indirection as you need just keeping existing terms.

I see.  Then we're removing Database interface and simplifying
ContextPartition. :)

> >If once the behavior of Database is defined in detail, we will be able
> >to create concrete implementation of
> >frontend to Database, and users won't need to reimplement it and just
> >use it.  So we can hide it easily:
> This front end is what the ContextPartitionConfiguration?  Or is it what
> the ContextPartition used to be?  Getting a little confused here.

The 'comcrete implementation' here is RootNexus that translates
complex operations into smaller pieces.  But I'm not sure its the duty
of RootNexus.  We could do that somewhere else like

> >ContextPartitionConfiguration cfg = ...;
> >cfg.setDatabase( new InMemoryDatabase() );
> But people will implement their own databases and there will be more
> than one.  Above you say the that a concrete implementation of the
> Database will not have to be reimplemented.  Users want to do this.

Database should be reimplemented by users of course if they are not
using JDBM backend for example.  The concrete implementation is
frontend part that translates JNDI operations into Database (or
ContextPartition if we use the new term) operations.

> >The role of DatabaseNexus is similar to that of RootNexus.  We could
> >forward any operations to appropriate Database implementation.  Using
> >DatabaseNexus, we will be able to make RootNexus just a frontend to
> >DatabaseNexus that translates complex JNDI operations into small
> >Database operations.
> Would the RootNexus still serve out the RootDSE? Like the translation
> aspect btw and it makes sense to have this be a ContextPartitionNexus.
> Then we can implement the functionality of the JIRA issue I listed above.

Right, it will have to move to ContextPartitionNexus.

> #3 is a great idea if the names are adjusted as I noted above.  This way
> the terminology people are used to associating with pluggable stores
> remains the same as a ContextPartition .. it just has interface changes
> and sits one level down after introducing another ContextPartitionNexus.

> >Plus we'll need to expose DatabaseNexus to Interceptors for
> >interceptors that need a fine-grained control over database.
> Yep I understand this and ContextPartitionConfiguration is the best way
> to give them what they need or am I mistaken?

What about just adding RootNexus.getContextPartitions() method that
returns a ContextPartitionNexus as ContextPartition type?

what we call human nature is actually human habit

View raw message