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 Tue, 21 Jun 2005 02:00:34 GMT
Hi Emmanuel,

2005/6/19, Emmanuel Lecharny <>:
> Not so sure. You have two basic choices here :
> - use a specific indexed Database (BDB, or whatever fit your needs)
> - use a classic relationnal Database (Or*cle(TM), Posgresql,
> MySql, ...)
> I bet that if you are to use ApacheDS in production, you will favor
> reliability above performance. This will be the choice of many clients,
> I assure you ! Not that performance is not important, but clients hate
> to loose data, strange enough ;)
> Or*cle(TM) has implemented a new hierarchical engine in V10, which
> improve greatly performances for data which has this kind of structure.
> Whatever, I really buy your idea to have the simplest interface as
> possible, because it will help to implements any kind of backend
> Databse.

Thanks for your information, and now I moved most BTree-specific
classes to btree package, so it will be more clear to implement those
context partitions.

> There is also a point that I want to rise : a Modify request does not
> give you the attributes of an entry, as you perfectly know. So a Put
> will be quite complicated to implement, as you won't be able to deal
> with deleted attributes without fetching the full entry before. So the
> sequence will be :
> - fetch the entry from the Database
> - modify the entry in memory
> - update the entry into the database
> It will be very costly.
> I also bet that we won't have ten thousands of Database to deal with, so
> even if the proposed interface is a little bit more complicated than
> just a Put and a Delete, it's not a big deal.

Right, so I retained current API.

> So your NotDeletingDatabase is still seen as a Database, am I wrong? If
> so, this is quite a smart idea. The end user should not know what's
> going on in the kitchen, he just want to have good food in his plate !

Yes exactly, but I found it is more powerful to make interceptor look
more like ContextPartitions to reduce impedence mismatch between
Interceptor and ContextPartition.  I'll show how can I make this
happen today or tomorrow.

> Much more important : just add transaction because it's a must. This is
> something I always had problem with OpenLdap, because updates are
> dangerous on a running environment. If you change an information, you
> can't guaranty that somebody is already using it. The problem is that
> you have to extend the transaction mechanism to reads, because you want
> a reader to have a fresh entry, not something that is currently being
> modified. (Updating en entry can be something costly, if you store
> images, so this is a scenario which could occur)

Right, I'm trying to find out the best way to add transaction support now.

> > 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)
> +1, but can you develop a little bit what you mean by 'two modify
> operations are delegated to one modify method after some
> normalization' ?

I thought wrong by mistake just ignore it please. :)

> > 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
> > phase.
> +1

I've done this in the branch. :)

> really cool, and we need it actually, we will have 30° today here in
> Paris ;)

It's also hot here in South Korea.  I'd like drink a cup of Chi Chi cocktail! :)

what we call human nature is actually human habit

View raw message