fix different issues with referrals in searches; remove unused tests; cleanup referrals in tests so that they don't get chased; improve schema checking in modrdn and updates in general; minor cleanup

more definitive improvements; now write operations are consistent; plugged some more leaks/invalid frees; tests are more complete.  IBM db2 doesn't pass write test because the entries are written in a different order; need to write a script that sorts the results...

allow to search for "auxiliary" objectClasses (i.e. those in ldap_entry_objclasses); allow to return all objectClasses including "auxiliary"; various cleanup

remove {} from procedures invocation, as noted in ITS#2641; copied annotations from postgres example

should improve readability and (hopefully) decrease traffic on openldap-software; sorry I can't test it right now

Apply to Makefile as well

Add OpenLDAP copyright statement

Now related ITSes need be audited and possibly closed.

Enhancements:
  - re-styled code for better readability
  - upgraded backend API to reflect recent changes
  - LDAP schema is checked when loading SQL/LDAP mapping
  - AttributeDescription/ObjectClass pointers used for more efficient
    mapping lookup
  - bervals used where string length is required often
  - atomized write operations by committing at the end of each operation
    and defaulting connection closure to rollback
  - added LDAP access control to write operations
  - fully implemented modrdn (with rdn attrs change, deleteoldrdn,
    access check, parent/children check and more)
  - added parent access control, children control to delete operation
  - added structuralObjectClass operational attribute check and
    value return on search
  - added hasSubordinate operational attribute on demand
  - search limits are appropriately enforced
  - function backsql_strcat() has been made more efficient
  - concat function has been made configurable by means of a pattern
  - added config switches:
      - fail_if_no_mapping	write operations fail if there is no mapping
      - has_ldapinfo_dn_ru	overrides autodetect
      - concat_pattern		a string containing two '?' is used
				(note that "?||?" should be more portable
				than builtin function "CONCAT(?,?)")
      - strcast_func		cast of string constants in "SELECT DISTINCT					statements (needed by PostgreSQL)
      - upper_needs_cast	cast the argument of upper when required
				(basically when building dn substring queries)

Todo:
  - add security checks for SQL statements that can be injected (?)
  - re-test with previously supported RDBMs
  - replace dn_ru and so with normalized dn (no need for upper() and so
    in dn match)
  - implement a backsql_normalize() function to replace the upper()
    conversion routines
  - note that subtree deletion, subtree renaming and so could be easily
    implemented (rollback and consistency checks are available :)
  - implement "lastmod" and other operational stuff (ldap_entries table ?)

- now all write operations appear to work correctly with PostgeSQL 7.0
- all write operations have been made transactional (atomic writes to
  entries are committed separately only in case of complete^1 success
  while all other operations are rolled-back by default)
- more cleanup and handling of exceptional conditions

TODO:
- deen to check with different databases and more up to date versions
  of both unixODBC and PostgreSQL.

^1: attribute add/modify/delete operations silently succeed if the
    appropriate add/delete proc does not exist for each attribute;
    this may be correct to hide undesired/unimplemented correspondence
    between LDAP and SQL databases; however, a more appropriate
    LDAP behavior would be a failure with LDAP_UNAVAILABLE if a
    single write operation cannot be executed for such reason

Summary of changes is cited below.
The patch still needs some cosmetic changes to be made, but is ready for testing.

-----Original Message-----
From: Sam Drake [mailto:drake@timesten.com]
Sent: Saturday, April 07, 2001 10:40 PM
To: 'mitya@seismic.ru'
Cc: openldap-devel@OpenLDAP.org
Subject: RE: Slapd frontend performance issues


FYI, here is a short description of the changes I made.  I'll package up the
changes asap, but it may take a couple of days.

The performance numbers quoted in this report were seen at my location with
a 100,000 object database ... the slower numbers I mentioned earlier were
reported by a customer with a 1,000,000 object database.

I also can't explain the very poor performance I saw with OpenLDAP and LDBM
with a 100,000 object database.

...Sam Drake / TimesTen Performance Software

----------

Work Performed

OpenLDAP 2.0.9, including back-sql, was built successfully on Solaris
8 using gcc.  The LDAP server itself, slapd, passed all tests bundled
with OpenLDAP.  OpenLDAP was built using Sleepycat LDBM release 3.1.17
as the "native" storage manager.

The experimental back-sql facility in slapd was also built
successfully.  It was built using Oracle release 8.1.7 and the Oracle
ODBC driver and ODBC Driver Manager from Merant.  Rudimentary testing
was performed with the data and examples provided with back-sql, and
back-sql was found to be functional.

Slapd and back-sql were then tested with TimesTen, using TimesTen
4.1.1.  Back-sql was not immediately functional with TimesTen due to a
number of SQL limitations in the TimesTen product.

Functional issues encountered were:

1. Back-sql issued SELECT statements including the construct,
   "UPPER(?)".  While TimesTen supports UPPER, it does not support the
   use of parameters as input to builtin functions.  Back-sql was
   modified to convert the parameter to upper case prior to giving it
   to the underlying database ... a change that is appropriate for all
   databases.

2. Back-sql issued SELECT statements using the SQL CONCAT function.
   TimesTen does not support this function.  Back-sql was modified to
   concatentate the necessary strings itself (in "C" code) prior to
   passing the parameters to SQL.  This change is also appropriate for
   all databases, not just TimesTen.

Once these two issues were resolved, back-sql could successfully
process LDAP searches using the sample data and examples provided with
back-sql.

While performance was not measured at this point, numerous serious
performance problems were observed with the back-sql code and the
generated SQL.  In particular:

1. In the process of implementing an LDAP search, back-sql will
   generate and execute a SQL query for all object classes stored in
   back-sql.  During the source of generating each SQL query, it is
   common for back-sql to determine that a particular object class can
   not possibly have any members satisfying the search.  For example,
   this can occur if the query searches an attribute of the LDAP
   object that does not exist in the SQL schema.  In this case,
   back-sql would generate and issue the SQL query anyway, including a
   clause such as "WHERE 1=0" in the generated SELECT.  The overhead
   of parsing, optimizing and executing the query is non-trivial, and
   the answer (the empty set) is known in advance. Solution: Back-sql
   was modified to stop executing a SQL query when it can be
   predetermined that the query will return no rows.

2. Searches in LDAP are fundamentally case-insensitive ("abc" is equal
   to "aBc").  However, in SQL this is not normally the case.
   Back-sql thus generated SQL SELECT statements including clauses of
   the form, "WHERE UPPER(attribute) = 'JOE'".  Even if an index is
   defined on the attribute in the relational database, the index can
   not be used to satisfy the query, as the index is case sensitive.
   The relational database then is forced to scan all rows in the
   table in order to satisfy the query ... an expensive and
   non-scalable proposition.  Solution: Back-sql was modified to allow
   the schema designer to add additional "upper cased" columns to the
   SQL schema.  These columns, if present, contain an upper cased
   version of the "standard" field, and will be used preferentially
   for searching.  Such columns can be provided for all searchable
   columns, some columns, or no columns.  An application using
   database "triggers" or similar mechanisms can automatically
   maintain these upper cased columns when the standard column is
   changed.

3. In order to implement the hierarchical nature of LDAP object
   hierarchies, OpenLDAP uses suffix searches in SQL.  For example, to
   find all objects in the subtree "o=TimesTen,c=us", a SQL SELECT
   statement of the form, "WHERE UPPER(dn) LIKE '%O=TIMESTEN,C=US'"
   would be employed.  Aside from the UPPER issue discussed above, a
   second performance problem in this query is the use of suffix
   search.  In TimesTen (and most relational databases), indexes can
   be used to optimize exact-match searches and prefix searches.
   However, suffix searches must be performed by scanning every row in
   the table ... an expensive and non-scalable proposition.  Solution:
   Back-sql was modified to optionally add a new "dn_ru" column to the
   ldap_entries table.  This additional column, if present, contains a
   byte-reversed and upper cased version of the DN.  This allows
   back-sql to generate indexable prefix searches.  This column is
   also easily maintained automatically through the use of triggers.

Results

A simple database schema was generated holding the LDAP objects and
attributes specified by our customer.  An application was written to
generate test databases.  Both TimesTen and Oracle 8.1.7 were
populated with 100,000 entry databases.

Load Times

Using "slapadd" followed by "slapindex", loading and indexing 100,000
entries in an LDBM database ran for 19 minutes 10 seconds.

Using a C++ application that used ODBC, loading 100,000 entries into
a disk based RDBMS took 17 minutes 53 seconds.

Using a C++ application that used ODBC, loading 100,000 entries into
TimesTen took 1 minute 40 seconds.

Search Times

The command, "timex timesearch.sh '(cn=fname210100*)'" was used to
test search times.  This command issues the same LDAP search 4000
times over a single LDAP connection.  Both the client and server
(slapd) were run on the same machine.

With TimesTen as the database, 4000 queries took 14.93 seconds, for a
rate of 267.9 per second.

With a disk based RDBMS as the database, 4000 queries took 77.79 seconds,
for a
rate of 51.42 per second.

With LDBM as the database, 1 query takes 76 seconds, or 0.076 per
second.  Something is clearly broken.

including:
- fixes according to new API changes
- closing db connection in connection_destroy callback, not unbind
- support of new schema code, samples changed accordingly
- support for multiple objectclasses (to distinguish from unique objectclass-to-tables mapping)
- auto 'ref' attribute support
- samples now include illustrations of using these 2 features to make named referrals as described in ldapext-namedref draft

more to come:
- documentation update
- different improvements to be more close to native directory (after beta?)

- filter -> SQL translation bugfixes
- several memory leaks fixups
- improved configurability:
    - allows definition of  uppercasing function to support CIS matching on databases that do
    case sensitive compares (this fixes up Oracle issues, example updated)
    - allows more flexibility in stored procedures interface (different parameter order, optional return
      codes - see samples, and comments in backsql.h)
- synchronize function interfaces to recent changes in prototypes ("const" clauses etc.) made for all backends
  (those changes led to compile-time errors)