Re: RE : RE : problems with back-sql

["Pierangelo Masarati" <ando@sys-net.it>]

> I have just performed some more tests on search operations and found
> some new problems which seems to be DB-independent :
> - a search request like (!<some attribute>=<some value>) should select
> the entries which do not have <some attribute>; with back-sql only
> entries which have at least one value for <some attribute> are selected.
> The problem is that the request to select candidate entries perform a
> join on the attribute in the filter (excluding entries without the
> attribute). Consequently, the search request (!<some attribute>=*) does
> not select any entry.

This is a known limitation cuased by the design of the backend;
some filters may not generate complete queries.  We might need
to think about a different design, if feasible.

> - filters containing attributes with special syntax (e.g telephonenumber
> in which dash and space must be ignored) are badly processed in case you
> give a complete value (telephonenumber=332-2334). I think that the
> problem is that the value in the filter is "normalised", whereas it is
> not in the DB data.

This is limitation cannot be overcome, since filter attribute
normalization occurs before the backend is invoked; in this
sense, the data in the database should be normalized accordingly,
or queries should occur on normalized values according to LDAP
specifications (which is pretty unreasonable, I understand).
Some rdbms may allow special operations, like defining
"normalization" functions to be invoked when filtering data.
In these cases back-sql might be extended to consider data syntax
and take appropriate measures where available.  I am considering
this possibility.

> - filters on dname syntax attributes do not work (e.g documentdn in the
> samples). In the traces, we can see that the generated SQL request
> contains ...AND ldap_entries.oc_map_id = 1 AND ldap_entries.oc_map_id
> 2... (1 being the person object id and 2 being the document object id).

Again the design of these quesries need to be reworked

>
> Do you think I should issue one ITS for each problem, one ITS for all,
> or no ITS at all ???

I'd favour different ITSes, definitely.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it