directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Value classes refactoring
Date Thu, 24 Mar 2016 09:07:42 GMT
Le 24/03/16 09:08, Radovan Semancik a écrit :
> Hi,
> Looks good from my point of view. However, now we are getting very
> close to midPoint feature freeze, so I will be able to really test all
> of this only in the next cycle (approx. June). But I think you are
> doing the right thing.
I think that will fit. I don't expect to have too much time in the two
next months, so June is a decent timeframe for me. I don't think you
need those changes in the API atm anyway.
FTR, I'm adding some missing declarations for the PermissiveControl you
have added last week (OSGI imports/exports, bundle activator declaration).

We probably need to cut a release, and it's probably going to be a
1.0-RC1. I keep teh refactoring for a 2.0.
> BTW: PrepareString. Have you considered doing it in a lazy fashion?
> E.g. prepare the string only if someone asks for it and then store the
> prepared value for the entire Value lifetime. If Value is immutable
> then this approach should be safe.
That's a possibility. As I said, PrepareString is only needed when you
need to compare values. Sadly, we can't really tell when it's necessary,
except for some specific use case where we have such an information :
typically, for indexed attributes which will always require a
PrepareString. But we also need it when the attribute is not indexed but
is present in a filter, or when it's part of a Compare operation.

I think a balanced choice would be to always PrepareString the values
for indexed attributes (and store it on the backend, to avoid doing it
again and again), and do it on the fly when it's for an filter or a
compare operation. That shoudl save CPU cycles.

View raw message