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