Quanah Gibson-Mount wrote:

Maybe unrelated, but this reminds me of the issue I ran into with valsort where adding ordering made it so that I couldn't search on the non-weighted values

DO you mean values without {X} intermixed with values with {X}? I'm not sure I understand all the implications of ordering.

in the attr if it gets indexed, essentially requiring there to be two attributes for any weighted attribute if you needed indexing. For example "ou" and a private namespace "zimbraOU" or something.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------

Quanah Gibson-Mount wrote:

--On Friday, August 24, 2007 5:03 PM +0200 Pierangelo Masarati ando@sys-net.it wrote:

...

I'm implementing the Control syntax in draft-chu-ldap-logschema, which is used for the reqControls and reqRespControls as X-ORDERED 'VALUES', and I'm having a little bit of trouble in understanding how I should encode values. Right now, I'm putting the DER encoded controls in the pretty values, and the control OID in the normalized values as per the objectIdentifierFirstComponentMatch equality matching rule. However, it's not clear whether I should put the ordering prefix in either value. If I do, matching fails because test_filter() ignores the fact that an attribute may be ordered; in fact, it uses value_match() instead of ordered_value_match(). I suspect this is a bug, but I might be missing something __really__ obvious...

Maybe unrelated, but this reminds me of the issue I ran into with valsort where adding ordering made it so that I couldn't search on the non-weighted values in the attr if it gets indexed, essentially requiring there to be two attributes for any weighted attribute if you needed indexing. For example "ou" and a private namespace "zimbraOU" or something.

I suspect the same issue will exist with ordered values, but with ordered values we can actually fix it since the schema for the attribute lets us know that special treatment is needed. With valsort, nothing outside of the overlay knows that anything special is going on.