| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
* Check for BETXN support at build-time, provide options for disabling
or requiring that it be available for build to succeed.
* Track whether or not BETXN support is enabled in the plugin-local
state.
* Skip processing in post/internalpost callbacks if BETXN support is enabled.
* Skip work in betxnpost callbacks if BETXN support is disabled.
|
|
|
|
|
|
|
| |
Transaction support the way we added it is an all-or-nothing proposition
for a server installation, which turned out to be problematic, so 389 is
going to pursue another strategy for that. The new way requires that we
not register as a betxn plugin, ever.
|
| |
|
|
|
|
|
|
| |
already have, so that we can pass the transaction ID around; this
includes additional parameters for a number of functions and a new
callback data type for backend_set_config_entry_add_cb()
|
|
|
|
| |
passing the TXN ID around, which means we deadlock if we actually do it
|
|
|
|
| |
registration to it, let callback registration return error codes
|
|
|
|
|
| |
- warn if a map is going to be empty, because it usually signals a
misconfiguration of some kind
|
|
|
|
| |
value, for when we want to remove a default key-format and add a keys-format
|
| |
|
| |
|
|
|
|
|
| |
just expect the specific backend to return a filter when checking if an entry
is is a set configuration
|
| |
|
|
- start adding configuration for the schema plugin
|