Hi Emmanuel, 2005/6/19, Emmanuel Lecharny <[EMAIL PROTECTED]>: > 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! :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/
