Ivan Shmakov writes:
> >>>>> Hallvard B Furuseth <h.b.furuseth...> writes:
>
> > Solutions:
> > * Make a single attribute with all three values.
> > attribute "position", values ("a 1 9", "b 2 8", "c 3 7").
> > Syntax Directory String or IA5 String, plus a client-defined syntax
> > which clients are responsible for writing and parsing.
>
> Any particular reason not to have a multi-value attribute?
Client requirements, if some clients wants each value in a single
attribute.
Filtering, as you mention below.
> > * Create an attribute option range "coordinate-<system name>" so that
> > you can create one attribute description set for each coordinate
> > system:
> > attribute "latitude;coordinate-a", value "1"
> > attribute "latitude;coordinate-b", value "2"
> > attribute "latitude;coordinate-c", value "3"
> > attribute "longitude;coordinate-a", value "9"
> > attribute "longitude;coordinate-b", value "8"
> > attribute "longitude;coordinate-c", value "7"
>
> IIUC, this will preclude the DSA from maintaining consistency,
> as nothing's going to prevent the client from inserting, e. g.,
> latitude;coordinate-a but not longitude;coordinate-a?
Right. But then, nothing prevents the client from creating position
attributes either, since syntax checking is on the client side.
> OTOH, there'd be no way to make multiple (latitude, longitude)
> pairs given a single coordinate system.
True. Well, one could add a distinguising number in the "coordinate"
attribute (see example below), but it does get quite cumbersome.
> Given the schema above, would it be possible to make an LDAP
> filter for the points lying within a rectangular region (like:
> latitude is between 50 and 55, longitude is between 79 and 89)?
With the values in different attibutes, you can search for
(&(latitude>=50)(latitude<=55)(longitude>=79)(longitude<=89))
if you define ORDERING matching rules for the attributes.
Note however that this doesn't work right with multi-valued attrs,
even if you disambiguate them somehow: It will match e.g. this:
latitude;coordinate-a-value1: 10
longitude;coordinate-a-value1: 20
latitude;coordinate-a-value1: 60
longitude;coordinate-a-value1: 89.5
To get around that you'd need to stuff each position into a separate
entry.
With a single "all in one" position attribute, no it's not possible -
unless you write a server plugin which defines a new syntax and matching
rule. Even with simpler searches you need substring search which is
more expensive in the server than equality search, and also the filter
must somehow distinguish latitude from longitude. Come to think of it,
putting N and W in front of the numbers will help that a bit -- front
rather than back to make search for an approximate location possible.
Filter *W23* is more helpful than "*23*W*".
Also, unless you have a small database you'll want a syntax which the
server can index for efficient ORDERING searches. With OpenLDAP I think
that would have to be INTEGER. Which maybe leads you to create
supplementary attributes that can be indexed for ordering, in addition
to more detailed attributes with the real values...
An entirely different approach would be to store this in an SQL database
on the server and define some magic filter strings that translate into
proper SQL searches, where you can do complex filtering like that. That
way you'll in effect just be using LDAP as a cumbersome access control
to SQL. Don't know if any LDAP servers support that though.
--
Hallvard
