the necessary holes to make it work: this change supports checkpoints
of specific target objects (table:foo), but doesn't support generic
database checkpoints (they don't currently fail, but that's because
they don't do anything at all).
Turn off named checkpoints in test/format, when running with the
memrata device.
separate thread because it's possible to copy data out of the cache
without acquiring a lock, so there should be a reasonable amount of
overlap).
Fix a bug in the cache vs. primary comparison code, we were comparing
the value, not the key.
The WT_EXTENSION_API.transaction_oldest method doesn't require a
WT_SESSION handle, simplify it.
Minor re-ordering of the shared library load/unload code to simplify
error handling.
Check if the update can proceed on inserts and updatest, fix the overwrite
stuff (again). Probably still wrong, but I'll wait until I can run the
test suite to fix it.
Add support for setting the transaction state on commit/rollback; walk
the session handle and for every data-source cursor, call an underlying
commit or rollback function. I don't see another solution, so I'm doing
this until Michael weighs in: I'm adding private WT_CURSOR methods the
data-source code sets, which is flatly wrong, but the other approaches
seem worse.
Another WT_EXTENSION_API method: the transaction_snapshot_isolation method
returns if snapshot isolation is configured for the current transaction.
Change the WT_EXTENSION_API transaction_id method to return the transaction
ID; it's no more likely to fail than the other transaction methods, and
I don't see them failing in the future either. It's a little dangerous,
but I'd rather keep error handling simple if we can.
(this version mostly works, supporting the cursor methods other than
search-near).
Add support for two new WT_EXTENSION API methods, collator_config and
collator; the former connects the current sessions collation cookie
to the WT_EXTENSION structure, the second calls it. This is required
for the underlying data-source if it needs to order key/value pairs.
WT_DATA_SOURCE handles, called when the handle is discarded,
intended to allow general cleanup when the database is closed.
Re-work the BDB KVS and Memrata support to handle multiple open
databases, that is, get rid of all of the globals.
builds cleanly so I'm going to commit it). Change the extension API
handle methods to take the handle as their first argument, get rid of
the WT_EXTENSION_API.default_session method, instead, store a reference
to the enclosing WT_CONNECTION in the extension handle.
This push also includes a few changes that are part of creating a STEC
data source.
a WT_CONNECTION, we need a session to use the other WT_EXTENSION_API
methods.
Remove the "exclusive" argument to the WT_DATA_SOURCE.create method:
we handle it internally and it's not documented anywhere (besides it's
not standard for the WT_SESSION.create method, if the WT_SESSION.create
method needs it, it should retrieve it from the configuration information).
We can't stack a random set of entries into a cfg[] because we don't
want to allocate memory in the API. Instead, whenever a method's
arguments are reconfigured, re-build the base configuration string by
appending the new configuration, and re-build the checks array, that way
we always have a single base configuration string and a single checks
array.
Re-work how we're handling lists, we can't expect the application to
crack them, they can be seriously messy. If it's a list, create an
array of NULL-terminated refrences to nul-terminated strings (create
an "argv" array, in other words). It's ugly, and the user has to free
the memory, but I don't see an alternative.