Sorry took me a while since I had some investigation to do before
responding.
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 );
tx.commit();
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?
http://issues.apache.org/jira/browse/DIREVE-23
Also these changes will not break alias dereferencing I hope as its
documented here:
http://ldapd.sourceforge.net/dist/Aliases%20and%20Search.pdf
(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.
Alex
