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 09:26:47 GMT
Hi Emmanuel,

2005/6/19, Emmanuel Lecharny <>:
> > * Put (used to add and replace entries)
> > * Remove (used to delete entries)
> I suggest that you keep an operation to change entries. It may be much
> faster to do a Change than to do a Remove/Put. Even a Put instead of a
> Change can be costly, as all the elements of an entry are to be updated,
> which could cost a lot. Obviously, it depends on the underlying
> database !

If you're going to change an entry, put operation will be sufficient. 
But if underlying database implementaion stores attributes sparsely,
it can be insuffucient of course.  I guess that kind of implementation
will be rare and can be improved by using cache IMHO, so the problem
here is possibly moving or renaming.

The reason why I proposed these simple operations were actually to
create an interceptor that supresses delete operation and marks the
target entry as 'deleted' instead of deleting it really.  I was able
to simplify the implementation of that filter using this ways.  But
now I found that we can implement NotDeletingDatabase which wraps
existing Database to intercept delete, move or modifyRN operations and
fulfill my aim, and of course, retaining current Database interface.

But my idea on DatabaseContextPartition is still valid.  Users who
want to implement partition like LDAP proxy will have to implement
ContextPartition directly, but users who wants to use ApacheDS's
Database support will have to extend DatabaseContextPartition.   For
now, AbstractContextPartition and ApplicationContextPartition seems to
do what DatabaseContextPartition should do.

So.. here's my more refined idea:

1) create a new package 'partition' and place all partition related
stuffs there for better package layout.
2) merge AbstractContextPartition and ApplicationContextPartition to
3) move db package into 'partition' package. (i.e. partition.database)
and put DatabaseContextPartition to 'database' package for better
package layout.
4) retain the interface of current Database class, and add transaction
support to make all operations atomic.
5) add AbstractDatabase class that helps users to implement databases
easily.  (e.g. two modify operations are delegated to one modify
method after some normalization)
6) provide standardized initialization method like 'open' instead of
constructors like we did for ContextPartition so that users can
instantiate Database and DatabaseContextPartition in configuration

I must admit that my first idea was a kind of expression of
stupidness.  But this discussion led me to find out more better
solutions.  I think I'll satisfy with these 6 improbements.

> Put aside the previous comment, I really like the Tx stuff. This is
> something that many LDAP implementations don't have.

Yeah we'll be able to put quite useful metadata to Database. Cool? :)

Thanks for everyone's feedback!

what we call human nature is actually human habit

View raw message