objectClass("Employee") {
delete {
enabled false
}
}
SQL delete operation
|
Since 4.11
This functionality is available since version 4.11.
|
Delete operations remove the row matching the exact UID with a transactional SQL DELETE.
This article is part of the SQL connector development reference and guidance materials. See How to develop connectors using the SQL framework for the section introduction.
Basic delete
For a writable table, delete works out of the box — no operation script is required.
The framework:
-
Builds a
DELETEstatement with the full UID mapping as an exact predicate (for composite UIDs, all key columns are matched). -
Executes the statement inside a JDBC transaction.
-
Verifies that exactly one row was affected. The predicate is the full UID (primary key), so at most one row can match — the zero-row case fails with
UnknownUidException, and a defensive check raisesConnectorExceptionif the affected count is anything other than zero or one.
Connection failures are wrapped into ConnectionFailedException; failed transactions are rolled back.
Embedded child tables
Rows of detected child/embedded tables are managed by the parent object class (see Multitable support: child tables and junction tables) — embedded object classes themselves do not expose create, update or delete.
When the parent row is deleted, the connector first deletes the owned child-table rows and the junction-table rows, and only then deletes the parent row — all in the same transaction (see Writing to child and junction tables).
No cleanup is delegated to the database schema (for example foreign keys with ON DELETE CASCADE) — child rows are removed explicitly by the connector.
Enabling / disabling delete
The same in YAML:
objectClasses:
Employee:
delete:
enabled: false
Object classes marked readOnly true, and views, never get a delete handler.
See also built-in mapping rules.