Lorenzo Pastrana writes:
I can't find any mentions of floating point/real data types in ldap attributes syntax,
There is no standardized floating point LDAP syntax.
... Strange ? Isn't it ? Does someone knows what has been the rationale ?
I've been reading the laconic 'Numeric Sting' specifications : Would this work ok (matching & ordering) with a 1.997 value ?
No, Numeric String does not allow a decimal point.
6.23. Numeric String
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
The encoding of a string in this syntax is the string value itself. Example:
This is from the obsolete RFC 2251-2256 standards. Read the current LDAP standard instead, RFCs 4510-4519. Syntaxes are in RFC 4517.
Hurf ?! ... Great ! :/ Better starting point ...
Many things including syntaxes are described more carefully than in earlier RFCs. E.g. explanations have been copied from the X.500 standard so they can mostly be read without cross-referencing X.500.
If not, how do I get ldap to match and order floating point scalars ?
You have to implement them yourself - either in the client or in a module you "moduleload" into the server in slapd.conf.
Ok, I'll look at that ... my preference is for server side I guess.
Thanks very much.
LP
If you implement it in the client:
- Use a syntax like IA5 String or Octet String.
- These syntaxes' ORDERING rules sort as strings - so to get correct ordering you'll likely want to invent a format where memcmp(num1, num2) < 0 if num1 < num2.
- Store normalized values so they can be compared for equality. (E.g. if you use a text format, don't store trailing zeroes.)
You cannot index these syntaxes for inequality searches though. I.e. a search for (val<=3.1) will not use an index, it will examine each entry in scope.
If you implement in the server and want indexing for inequality to work, the values stored in the index file must be sortable. Look at integerIndexer()+integerFilter() in servers/slapd/schema_init.c for an example. An implementation in the server will also allow you to store non-normalized values and have the server normalize before comparing. (At the expense of some server-side CPU time, of course.)
Lorenzo Pastrana - Happy End Vision -------------------------- Design web Conception multimédia Communication visuelle et édition -------------------------- Tél. : 01 42 47 83 09 Fax : 01 47 70 70 19 E-mail : lorenzo.pastrana@happyend.fr
