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.
