I can't find any mentions of floating point/real data types in ldap attributes syntax, I've been reading the laconic 'Numeric Sting' specifications :
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:
1997
Would this work ok (matching & ordering) with a 1.997 value ? If not, how do I get ldap to match and order floating point scalars ?
Thanks. Lo.
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
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.
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. 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.
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.)
I wrote:
- 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.
Er, try "invent" -> "find", whether for client implementation or server-side index implementation. Floating point can be tricky to get quite right, in particular when NaN etc is included. Hopefully someone else has already needed sortable floating-point strings and invented them.
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
Lorenzo Pastrana writes:
There is no standardized floating point LDAP syntax.
... Strange ? Isn't it ? Does someone knows what has been the rationale ?
My guess: Small interest due to few mathematicians and scientists in the LDAP community. Each syntax and each matching rule takes some work to implement and make the LDAP implementation larger. So there are (too) few LDAP syntaxes and matching rules, but a great many things which sensibly could have use for them.
BTW, a quick Google turned up this: http://tools.ietf.org/html/draft-wood-ldapext-float-00 but note that the draft was abandoned - maybe for a good reason. You could ask the author.
ASN.1 (type/syntax system used by X.500) has a somewhat complicated "REAL" type you might look into.
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Lorenzo Pastrana