directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [apacheds] Idea on refactoring Database, ContextPartition, and RootNexus
Date Sun, 19 Jun 2005 05:53:24 GMT
Sorry took me a while since I had some investigation to do before 

Trustin Lee wrote:

>No we don't need that much, all we need is:
>* 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 

>We could be able to combine put and remove operation to move or rename
>entries, and therefore rename and move operation is splitted into many
>small operations, so we need transaction here:
>Database db = ...;
>Transaction tx = db.beginTransaction();
>tx.delete( entryWithOldName );
>tx.put( entryWithNewName );
Yep I'm following you.

>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?

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

(BTW I need to move this into our repo)

Also I have some terminology issues as you might expect.  First off I 
would like the data containing areas to be referred to as partitions.  
Reason being is they are subsets of the information served by the 
server.   The entire subsystem is the backend subsystem.  I don't want 
that mixed up with backend or database. 

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. 

>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.

>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.

>3) DatabaseNexus and RootNexus
>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.

#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?

>I attached class diagram and sequence diagram for this change to help
>you understand this easily.
Thanks for going out of your way to really make it easy to understand.  
Forgive me for having so many questions.


View raw message