directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: [ApacheDS] Porting 1.x based custom partition to 2.0
Date Tue, 27 Aug 2013 07:43:50 GMT
On Tue, Aug 27, 2013 at 1:02 PM, <> wrote:

> Over a year ago I developed a custom partition with ApacheDS that I want
> to port to 2.0 now. The partition is "special" because it is only used to
> connect to ApacheDS, the search in the sub tree is then taken care of in
> Javacode and not in a directory or database.
> The result for the query needs to be determined "live" without copying any
> data to ApacheDS beforehand.
> This is not my exact scenario but I want to give you an example which
> might explain what I want to do. Let's assume I want to use ApacheDS to
> look up square roots. It would not make sense to store all possible results
> in ApacheDS.
> A search for a square root would look like this:
> ldapsearch -b ou=squareroot -M -h localhost -p 389 -x "(value=25)"
> "squareroot" will be the name of the subtree / partition I write. The
> search is "value=25" which tells the partition that I want to receive the
> square root of 25. The partition would then simply calculate
> Math.sqrt(doubleTakenFromQuery) and return the value.
> So my questions are:
> 1. do you rate 2.0 as mature enough to build my solution on it ? (I assume
> yes but perhaps a certain Milestone is a better fit)
yes, the latest 2.0.0-M15 is a good candidate

> 2. is it still the best way to use a partition for this or does 2.0 offer
> better ways ?
considering the way your custom partition works it won't offer any real
benefit by migrating to 2.0
you don't use the ApacheDS's backends and this is where a lot of 2.0
related improvements are
besides the internal search engine

> 3. do you know of any examples for this for 2.0 ? I only know examples for
> 1.x and know that these won't work for 2.0
I guess not, I will update the example code to work with the latest trunk
and let you know

Kiran Ayyagari

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message