These statements are used to modify the default behavior of the
backend according to issues of the dialect of the RDBMS. The
first options essentially refer to string and DN normalization
when building filters. LDAP normalization is more than upper-
(or lower-)casing everything; however, as a reasonable trade-off,
for case-sensitive RDBMSes the backend can be instructed to
uppercase strings and DNs by providing the upper_func directive.
Some RDBMSes, to use functions on arbitrary data types, e.g.
string constants, requires a cast, which is triggered by the
upper_needs_cast directive. If required, a string cast function
can be provided as well, by using the strcast_func directive.
Finally, a custom string concatenation pattern may be required;
it is provided by the concat_pattern directive.
upper_func <SQL function name>
Specifies the name of a function that converts a given
value to uppercase. This is used for case insensitive
matching when the RDBMS is case sensitive. It may differ
from one SQL dialect to another (e.g. UCASE, UPPER or
whatever; see samples). By default, none is used, i.e.
strings are not uppercased, so matches may be case
sensitive.
upper_needs_cast { NO | yes }
Set this directive to yes if upper_func needs an explicit
cast when applied to literal strings. A cast in the form
CAST (<arg> AS VARCHAR(<max DN length>)) is used, where
<max DN length> is builtin in back-sql; see macro
BACKSQL_MAX_DN_LEN (currently 255; note that slapd's
builtin limit, in macro SLAP_LDAPDN_MAXLEN, is set to
8192). This is experimental and may change in future
releases.
strcast_func <SQL function name>
Specifies the name of a function that converts a given
value to a string for appropriate ordering. This is used
in "SELECT DISTINCT" statements for strongly typed RDBMSes
with little implicit casting (like PostgreSQL), when a
literal string is specified. This is experimental and may
change in future releases.
concat_pattern <pattern>
This statement defines the pattern that is used to
concatenate strings. The pattern MUST contain two
question marks, '?', that will be replaced by the two
strings that must be concatenated. The default value is
CONCAT(?,?); a form that is known to be highly portable
(IBM db2, PostgreSQL) is ?||?, but an explicit cast may be
required when operating on literal strings: CAST(?||? AS
VARCHAR(<length>)). On some RDBMSes (IBM db2, MSSQL) the
form ?+? is known to work as well. Carefully check the
documentation of your RDBMS or stay with the examples for
supported ones. This is experimental and may change in
future releases.
aliasing_keyword <string>
Define the aliasing keyword. Some RDBMSes use the word
"AS" (the default), others don't use any.
aliasing_quote <string>
Define the quoting char of the aliasing keyword. Some
RDBMSes don't require any (the default), others may
require single or double quotes.
has_ldapinfo_dn_ru { NO | yes }
Explicitly inform the backend whether the dn_ru column (DN
in reverse uppercased form) is present in table
ldap_entries. Overrides automatic check (this is
required, for instance, by PostgreSQL/unixODBC). This is
experimental and may change in future releases.
fail_if_no_mapping { NO | yes }
When set to yes it forces attribute write operations to
fail if no appropriate mapping between LDAP attributes and
SQL data is available. The default behavior is to ignore
those changes that cannot be mapped. It has no impact on
objectClass mapping, i.e. if the structuralObjectClass of
an entry cannot be mapped to SQL by looking up its name in
ldap_oc_mappings, an add operation will fail regardless of
the fail_if_no_mapping switch; see section
"METAINFORMATION USED" for details. This is experimental
and may change in future releases.
allow_orphans { NO | yes }
When set to yes orphaned entries (i.e. without the parent
entry in the database) can be added. This option should
be used with care, possibly in conjunction with some
special rule on the RDBMS side that dynamically creates
the missing parent.
baseObject [ <filename> ]
Instructs the database to create and manage an in-memory
baseObject entry instead of looking for one in the RDBMS.
If the (optional) <filename> argument is given, the entry
is read from that file in LDIF(5) format; otherwise, an
entry with objectClass extensibleObject is created based
on the contents of the RDN of the baseObject. This is
particularly useful when ldap_entries information is
stored in a view rather than in a table, and union is not
supported for views, so that the view can only specify one
rule to compute the entry structure for one objectClass.
This topic is discussed further in section
"METAINFORMATION USED". This is experimental and may
change in future releases.
create_needs_select { NO | yes }
Instructs the database whether or not entry creation in
table ldap_entries needs a subsequent select to collect
the automatically assigned ID, instead of being returned
by a stored procedure.
fetch_attrs <attrlist>
fetch_all_attrs { NO | yes }
The first statement allows one to provide a list of
attributes that must always be fetched in addition to
those requested by any specific operation, because they
are required for the proper usage of the backend. For
instance, all attributes used in ACLs should be listed
here. The second statement is a shortcut to require all
attributes to be always loaded. Note that the dynamically
generated attributes, e.g. hasSubordinates, entryDN and
other implementation dependent attributes are NOT
generated at this point, for consistency with the rest of
slapd. This may change in the future.
check_schema { YES | no }
Instructs the database to check schema adherence of
entries after modifications, and structural objectClass
chain when entries are built. By default it is set to
yes.
sqllayer <name> [...]
Loads the layer <name> onto a stack of helpers that are
used to map DNs from LDAP to SQL representation and vice-
versa. Subsequent args are passed to the layer
configuration routine. This is highly experimental and
should be used with extreme care. The API of the layers
is not frozen yet, so it is unpublished.
autocommit { NO | yes }
Activates autocommit; by default, it is off.
