Please see the user's guide for a full description of capabilties, etc.
1. Table's name in source defines the base DN (or context) for the search.
2. Column's name in source defines the LDAP attribute name.
[Default] If no name in source is defined, then we attempt to use the column name
as the LDAP attribute name.
3. Since all of the underlying LDAP methods for adding/deleting/updating
require specification of the LDAP distinguished name (DN) to change, for all
corresponding MetaMatrix operations the DN must be specified (as the sole
item in the WHERE clause for UPDATE and DELETE operations, and in the list
of attributes to assign values in an INSERT operation * Responsible for update/insert/delete operations against LDAP
execute generic update-class (either an update, delete, or insert)
operation and returns a count of affected rows. Since underlying
LDAP operations (and this connector) can modify at most one LDAP
leaf context at a time, this will always return 1. It will never
actually return 0, because if an operation fails, a
ConnectorException will be thrown instead.
Note that really it should return 0 if a delete is performed on
an entry that doesn't exist (but whose parent does exist), but
since the underlying LDAP operation will return success for such a
delete, we just blindly return 1. To return 0 would mean performing
a search for the entry first before deleting it (to confirm that it
did exist prior to the delete), so right now we sacrifice accuracy
here for the sake of efficiency.
Returns the update counts for the execution.
A single positive integer value is expected for non bulk/batch commands.
bulk/batch should return an integer for each value/command. 0 or greater for successful update count, -2 for no info, -3 failure