xuemingqiang/mongo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
9ba69ab7180c49c6a0f01b002a94e3a3798ec00a
mongo/examples/c/ex_data_source.c

674 lines
16 KiB
C
Raw Normal View History

Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*-
Upgrade copyright notices from 2015 to 2016.
2016-01-01 16:37:39 -05:00
* Public Domain 2014-2016 MongoDB, Inc.
Update copyright notices for 2014. Move lang/java and lang/python into the public domain.
2014-01-07 10:30:12 -05:00
* Public Domain 2008-2014 WiredTiger, Inc.
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
*
* This is free and unencumbered software released into the public domain.
*
* Anyone is free to copy, modify, publish, use, compile, sell, or
* distribute this software, either in source code form or as a compiled
* binary, for any purpose, commercial or non-commercial, and by any
* means.
*
* In jurisdictions that recognize copyright laws, the author or authors
* of this software dedicate any and all copyright interest in the
* software to the public domain. We make this dedication for the benefit
* of the public at large and to the detriment of our heirs and
* successors. We intend this dedication to be an overt act of
* relinquishment in perpetuity of all present and future rights to this
* software under copyright law.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
* IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
* OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*
* ex_data_source.c
* demonstrates how to create and access a data source
*/
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
#include <errno.h>
#include <stdio.h>
Add a small example for list using strsep -- I'm pretty sure this is wrong, but it's a placeholder.
2013-04-11 09:34:19 -04:00
#include <stdlib.h>
#include <string.h>
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
#include <wiredtiger.h>
/*! [WT_EXTENSION_API declaration] */
#include <wiredtiger_ext.h>
static WT_EXTENSION_API *wt_api;
Data source cleanup: fix some build warnings, exclude new function from the Java API, allow enough space in the wiredtiger_open cfg stack for a WIREDTIGER_CONFIG environment variable.
2013-04-12 11:01:12 +10:00
static void
minor cleanup, remove unnecessary documentation chunk.
2013-04-20 11:27:56 -04:00
my_data_source_init(WT_CONNECTION *connection)
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
{
minor cleanup, remove unnecessary documentation chunk.
2013-04-20 11:27:56 -04:00
wt_api = connection->get_extension_api(connection);
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
}
/*! [WT_EXTENSION_API declaration] */
/*! [WT_DATA_SOURCE create] */
static int
Use an opaque type for config arguments passed to callbacks, rather than void *.
2013-04-18 16:51:20 +10:00
my_create(WT_DATA_SOURCE *dsrc, WT_SESSION *session,
const char *uri, WT_CONFIG_ARG *config)
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE create] */
{
/* Unused parameters */
(void)dsrc;
(void)uri;
(void)config;
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
{
const char *msg = "string";
/*! [WT_EXTENSION_API err_printf] */
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
(void)wt_api->err_printf(
wt_api, session, "extension error message: %s", msg);
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
/*! [WT_EXTENSION_API err_printf] */
}
{
const char *msg = "string";
/*! [WT_EXTENSION_API msg_printf] */
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
(void)wt_api->msg_printf(wt_api, session, "extension message: %s", msg);
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
/*! [WT_EXTENSION_API msg_printf] */
}
Add WT_EXTENSION_API::strerror so extensions don't have to load against the WiredTiger library in order to get to wiredtiger_strerror().
2013-04-20 11:02:00 -04:00
{
int ret = 0;
/*! [WT_EXTENSION_API strerror] */
Replace wiredtiger_strerror_r with WT_SESSION.strerror, reference #1516.
2015-02-02 19:20:33 -05:00
(void)wt_api->err_printf(wt_api, session,
"WiredTiger error return: %s",
wt_api->strerror(wt_api, session, ret));
Add WT_EXTENSION_API::strerror so extensions don't have to load against the WiredTiger library in order to get to wiredtiger_strerror().
2013-04-20 11:02:00 -04:00
/*! [WT_EXTENSION_API strerror] */
}
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
{
/*! [WT_EXTENSION_API scr_alloc] */
void *buffer;
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
if ((buffer = wt_api->scr_alloc(wt_api, session, 512)) == NULL) {
(void)wt_api->err_printf(wt_api, session,
Switch uses of wiredtiger_strerror() for WT_SESSION.strerror().
2015-03-20 17:46:54 -04:00
"buffer allocation: %s",
session->strerror(session, ENOMEM));
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
return (ENOMEM);
}
/*! [WT_EXTENSION_API scr_alloc] */
/*! [WT_EXTENSION_API scr_free] */
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
wt_api->scr_free(wt_api, session, buffer);
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
/*! [WT_EXTENSION_API scr_free] */
}
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
return (0);
}
/*! [WT_DATA_SOURCE compact] */
static int
my_compact(WT_DATA_SOURCE *dsrc, WT_SESSION *session,
Use an opaque type for config arguments passed to callbacks, rather than void *.
2013-04-18 16:51:20 +10:00
const char *uri, WT_CONFIG_ARG *config)
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE compact] */
{
/* Unused parameters */
(void)dsrc;
(void)session;
(void)uri;
(void)config;
return (0);
}
/*! [WT_DATA_SOURCE drop] */
static int
my_drop(WT_DATA_SOURCE *dsrc, WT_SESSION *session,
Use an opaque type for config arguments passed to callbacks, rather than void *.
2013-04-18 16:51:20 +10:00
const char *uri, WT_CONFIG_ARG *config)
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE drop] */
{
/* Unused parameters */
(void)dsrc;
(void)session;
(void)uri;
(void)config;
return (0);
}
Data source cleanup: fix some build warnings, exclude new function from the Java API, allow enough space in the wiredtiger_open cfg stack for a WIREDTIGER_CONFIG environment variable.
2013-04-12 11:01:12 +10:00
static int
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
data_source_cursor(void)
{
return (0);
}
Data source cleanup: fix some build warnings, exclude new function from the Java API, allow enough space in the wiredtiger_open cfg stack for a WIREDTIGER_CONFIG environment variable.
2013-04-12 11:01:12 +10:00
static const char *
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
data_source_error(int v)
{
return (v == 0 ? "one" : "two");
}
Replace the cursor commit/rollback functions with an extension API that allows the data-source to request notification when the transaction is committed or rolled back.
2013-07-09 12:53:45 -04:00
static int
data_source_notify(
Use an interface for WT_TXN_NOTIFY so it doesn't need a magic cookie.
2013-08-09 15:54:52 +10:00
WT_TXN_NOTIFY *handler, WT_SESSION *session, uint64_t txnid, int committed)
Replace the cursor commit/rollback functions with an extension API that allows the data-source to request notification when the transaction is committed or rolled back.
2013-07-09 12:53:45 -04:00
{
/* Unused parameters */
Use an interface for WT_TXN_NOTIFY so it doesn't need a magic cookie.
2013-08-09 15:54:52 +10:00
(void)handler;
Replace the cursor commit/rollback functions with an extension API that allows the data-source to request notification when the transaction is committed or rolled back.
2013-07-09 12:53:45 -04:00
(void)session;
(void)txnid;
(void)committed;
return (0);
}
Add some more structure to the data-source cursor-create example.
2013-06-10 09:33:26 -04:00
static int my_cursor_next(WT_CURSOR *wtcursor)
{ (void)wtcursor; return (0); }
static int my_cursor_prev(WT_CURSOR *wtcursor)
{ (void)wtcursor; return (0); }
static int my_cursor_reset(WT_CURSOR *wtcursor)
{ (void)wtcursor; return (0); }
static int my_cursor_search(WT_CURSOR *wtcursor)
{ (void)wtcursor; return (0); }
static int my_cursor_search_near(WT_CURSOR *wtcursor, int *exactp)
{ (void)wtcursor; (void)exactp; return (0); }
static int my_cursor_insert(WT_CURSOR *wtcursor)
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
{
WT_SESSION *session = NULL;
int ret;
lint
2013-07-04 12:47:47 -04:00
/* Unused parameters */
(void)wtcursor;
More transactional code for the Memrata device. 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.
2013-07-04 12:34:40 -04:00
{
Replace __wt_ext_transaction_snapshot_isolation() with __wt_ext_transaction_isolation_level().
2013-08-07 10:46:26 -04:00
int is_snapshot_isolation, isolation_level;
/*! [WT_EXTENSION transaction isolation level] */
isolation_level = wt_api->transaction_isolation_level(wt_api, session);
if (isolation_level == WT_TXN_ISO_SNAPSHOT)
is_snapshot_isolation = 1;
else
is_snapshot_isolation = 0;
/*! [WT_EXTENSION transaction isolation level] */
examples/c/ex_data_source.c:174:6: error: variable ‘is_snapshot_isolation’ set but not used [-Werror=unused-but-set-variable] examples/c/ex_data_source.c:168:6: error: variable ‘ret’ set but not used [-Werror=unused-but-set-variable]
2013-08-08 11:40:35 +10:00
(void)is_snapshot_isolation;
More transactional code for the Memrata device. 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.
2013-07-04 12:34:40 -04:00
}
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
{
/*! [WT_EXTENSION transaction ID] */
uint64_t transaction_id;
More transactional code for the Memrata device. 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.
2013-07-04 12:34:40 -04:00
transaction_id = wt_api->transaction_id(wt_api, session);
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
/*! [WT_EXTENSION transaction ID] */
More transactional code for the Memrata device. 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.
2013-07-04 12:34:40 -04:00
(void)transaction_id;
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
}
Add the WT_EXTENSION_API.transaction_oldest method to return the oldest transaction ID not yet visible to a running transaction.
2013-07-05 09:11:33 -04:00
{
/*! [WT_EXTENSION transaction oldest] */
uint64_t transaction_oldest;
Add a separate thread to migrate cache data into the primary (it's a 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.
2013-07-08 12:19:49 -04:00
transaction_oldest = wt_api->transaction_oldest(wt_api);
Add the WT_EXTENSION_API.transaction_oldest method to return the oldest transaction ID not yet visible to a running transaction.
2013-07-05 09:11:33 -04:00
/*! [WT_EXTENSION transaction oldest] */
(void)transaction_oldest;
}
Replace the cursor commit/rollback functions with an extension API that allows the data-source to request notification when the transaction is committed or rolled back.
2013-07-09 12:53:45 -04:00
{
Rename WT_EXTENSION_API.transaction_resolve to WT_EXTENSION_API.transaction_resolve.
2013-08-07 10:56:01 -04:00
/*! [WT_EXTENSION transaction notify] */
Use an interface for WT_TXN_NOTIFY so it doesn't need a magic cookie.
2013-08-09 15:54:52 +10:00
WT_TXN_NOTIFY handler;
handler.notify = data_source_notify;
ret = wt_api->transaction_notify(wt_api, session, &handler);
Rename WT_EXTENSION_API.transaction_resolve to WT_EXTENSION_API.transaction_resolve.
2013-08-07 10:56:01 -04:00
/*! [WT_EXTENSION transaction notify] */
Replace the cursor commit/rollback functions with an extension API that allows the data-source to request notification when the transaction is committed or rolled back.
2013-07-09 12:53:45 -04:00
}
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
{
uint64_t transaction_id = 1;
int is_visible;
/*! [WT_EXTENSION transaction visible] */
is_visible =
wt_api->transaction_visible(wt_api, session, transaction_id);
/*! [WT_EXTENSION transaction visible] */
(void)is_visible;
}
{
const char *key1 = NULL, *key2 = NULL;
Fix compiler warnings from OS X.
2013-08-16 14:08:47 +10:00
uint32_t key1_len = 0, key2_len = 0;
Add WT_COLLATOR::customize, allowing collators to be customized for specific data sources, or with application-managed metadata.
2014-08-15 18:02:25 +10:00
WT_COLLATOR *collator = NULL;
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
/*! [WT_EXTENSION collate] */
WT_ITEM first, second;
int cmp;
first.data = key1;
first.size = key1_len;
second.data = key2;
second.size = key2_len;
Add WT_COLLATOR::customize, allowing collators to be customized for specific data sources, or with application-managed metadata.
2014-08-15 18:02:25 +10:00
ret = wt_api->collate(wt_api, session, collator, &first, &second, &cmp);
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
if (cmp == 0)
printf("key1 collates identically to key2\n");
else if (cmp < 0)
printf("key1 collates less than key2\n");
else
printf("key1 collates greater than key2\n");
/*! [WT_EXTENSION collate] */
}
examples/c/ex_data_source.c:174:6: error: variable ‘is_snapshot_isolation’ set but not used [-Werror=unused-but-set-variable] examples/c/ex_data_source.c:168:6: error: variable ‘ret’ set but not used [-Werror=unused-but-set-variable]
2013-08-08 11:40:35 +10:00
return (ret);
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
}
Add some more structure to the data-source cursor-create example.
2013-06-10 09:33:26 -04:00
static int my_cursor_update(WT_CURSOR *wtcursor)
{ (void)wtcursor; return (0); }
static int my_cursor_remove(WT_CURSOR *wtcursor)
{ (void)wtcursor; return (0); }
static int my_cursor_close(WT_CURSOR *wtcursor)
{ (void)wtcursor; return (0); }
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE open_cursor] */
Add some more structure to the data-source cursor-create example.
2013-06-10 09:33:26 -04:00
typedef struct __my_cursor {
WT_CURSOR wtcursor; /* WiredTiger cursor, must come first */
/*
* Local cursor information: for example, we might want to have a
* reference to the extension functions.
*/
WT_EXTENSION_API *wtext; /* Extension functions */
} MY_CURSOR;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
static int
my_open_cursor(WT_DATA_SOURCE *dsrc, WT_SESSION *session,
Use an opaque type for config arguments passed to callbacks, rather than void *.
2013-04-18 16:51:20 +10:00
const char *uri, WT_CONFIG_ARG *config, WT_CURSOR **new_cursor)
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
{
Add some more structure to the data-source cursor-create example.
2013-06-10 09:33:26 -04:00
MY_CURSOR *cursor;
/* Allocate and initialize a WiredTiger cursor. */
if ((cursor = calloc(1, sizeof(*cursor))) == NULL)
return (errno);
cursor->wtcursor.next = my_cursor_next;
cursor->wtcursor.prev = my_cursor_prev;
cursor->wtcursor.reset = my_cursor_reset;
cursor->wtcursor.search = my_cursor_search;
cursor->wtcursor.search_near = my_cursor_search_near;
cursor->wtcursor.insert = my_cursor_insert;
cursor->wtcursor.update = my_cursor_update;
cursor->wtcursor.remove = my_cursor_remove;
cursor->wtcursor.close = my_cursor_close;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
Add some more structure to the data-source cursor-create example.
2013-06-10 09:33:26 -04:00
/*
* Configure local cursor information.
*/
/* Return combined cursor to WiredTiger. */
*new_cursor = (WT_CURSOR *)cursor;
/*! [WT_DATA_SOURCE open_cursor] */
{
int ret = 0;
(void)dsrc; /* Unused parameters */
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
(void)session;
(void)uri;
(void)new_cursor;
{
/*! [WT_EXTENSION_CONFIG boolean] */
Remove WT_EXTENSION_CONFIG, export WT_CONFIG_ITEM instead.
2013-04-17 13:46:43 -04:00
WT_CONFIG_ITEM v;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
int my_data_source_overwrite;
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
/*
* Retrieve the value of the boolean type configuration string
* "overwrite".
*/
Export more of the config parsing machinery to the extension API: we're going to need it at some point. --HG-- rename : src/config/config.c => src/config/config_ext.c
2013-04-18 22:46:00 +10:00
if ((ret = wt_api->config_get(
wt_api, session, config, "overwrite", &v)) != 0) {
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
(void)wt_api->err_printf(wt_api, session,
Switch uses of wiredtiger_strerror() for WT_SESSION.strerror().
2015-03-20 17:46:54 -04:00
"overwrite configuration: %s",
session->strerror(session, ret));
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
return (ret);
}
Remove WT_EXTENSION_CONFIG, export WT_CONFIG_ITEM instead.
2013-04-17 13:46:43 -04:00
my_data_source_overwrite = v.val != 0;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_EXTENSION_CONFIG boolean] */
Data source cleanup: fix some build warnings, exclude new function from the Java API, allow enough space in the wiredtiger_open cfg stack for a WIREDTIGER_CONFIG environment variable.
2013-04-12 11:01:12 +10:00
(void)my_data_source_overwrite;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
}
{
/*! [WT_EXTENSION_CONFIG integer] */
Remove WT_EXTENSION_CONFIG, export WT_CONFIG_ITEM instead.
2013-04-17 13:46:43 -04:00
WT_CONFIG_ITEM v;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
int64_t my_data_source_page_size;
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
/*
* Retrieve the value of the integer type configuration string
* "page_size".
*/
Export more of the config parsing machinery to the extension API: we're going to need it at some point. --HG-- rename : src/config/config.c => src/config/config_ext.c
2013-04-18 22:46:00 +10:00
if ((ret = wt_api->config_get(
wt_api, session, config, "page_size", &v)) != 0) {
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
(void)wt_api->err_printf(wt_api, session,
Switch uses of wiredtiger_strerror() for WT_SESSION.strerror().
2015-03-20 17:46:54 -04:00
"page_size configuration: %s",
session->strerror(session, ret));
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
return (ret);
}
Remove WT_EXTENSION_CONFIG, export WT_CONFIG_ITEM instead.
2013-04-17 13:46:43 -04:00
my_data_source_page_size = v.val;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_EXTENSION_CONFIG integer] */
Data source cleanup: fix some build warnings, exclude new function from the Java API, allow enough space in the wiredtiger_open cfg stack for a WIREDTIGER_CONFIG environment variable.
2013-04-12 11:01:12 +10:00
(void)my_data_source_page_size;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
}
{
Export more of the config parsing machinery to the extension API: we're going to need it at some point. --HG-- rename : src/config/config.c => src/config/config_ext.c
2013-04-18 22:46:00 +10:00
/*! [WT_EXTENSION config_get] */
Remove WT_EXTENSION_CONFIG, export WT_CONFIG_ITEM instead.
2013-04-17 13:46:43 -04:00
WT_CONFIG_ITEM v;
Add a small example for list using strsep -- I'm pretty sure this is wrong, but it's a placeholder.
2013-04-11 09:34:19 -04:00
const char *my_data_source_key;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
/*
* Retrieve the value of the string type configuration string
* "key_format".
*/
Export more of the config parsing machinery to the extension API: we're going to need it at some point. --HG-- rename : src/config/config.c => src/config/config_ext.c
2013-04-18 22:46:00 +10:00
if ((ret = wt_api->config_get(
wt_api, session, config, "key_format", &v)) != 0) {
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
(void)wt_api->err_printf(wt_api, session,
Switch uses of wiredtiger_strerror() for WT_SESSION.strerror().
2015-03-20 17:46:54 -04:00
"key_format configuration: %s",
session->strerror(session, ret));
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
return (ret);
}
/*
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
* Values returned from WT_EXTENSION_API::config in the str field are
* not nul-terminated; the associated length must be used instead.
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
*/
Remove WT_EXTENSION_CONFIG, export WT_CONFIG_ITEM instead.
2013-04-17 13:46:43 -04:00
if (v.len == 1 && v.str[0] == 'r')
Add a small example for list using strsep -- I'm pretty sure this is wrong, but it's a placeholder.
2013-04-11 09:34:19 -04:00
my_data_source_key = "recno";
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
else
Add a small example for list using strsep -- I'm pretty sure this is wrong, but it's a placeholder.
2013-04-11 09:34:19 -04:00
my_data_source_key = "bytestring";
Export more of the config parsing machinery to the extension API: we're going to need it at some point. --HG-- rename : src/config/config.c => src/config/config_ext.c
2013-04-18 22:46:00 +10:00
/*! [WT_EXTENSION config_get] */
Data source cleanup: fix some build warnings, exclude new function from the Java API, allow enough space in the wiredtiger_open cfg stack for a WIREDTIGER_CONFIG environment variable.
2013-04-12 11:01:12 +10:00
(void)my_data_source_key;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
}
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
{
/*! [WT_EXTENSION collator config] */
Add WT_COLLATOR::customize, allowing collators to be customized for specific data sources, or with application-managed metadata.
2014-08-15 18:02:25 +10:00
WT_COLLATOR *collator;
int collator_owned;
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
/*
* Configure the appropriate collator.
*/
Fix custom collators with LSM (and other non-btree sources): don't assume there is a data handle in the session.
2014-11-10 22:19:43 +11:00
if ((ret = wt_api->collator_config(wt_api, session,
"dsrc:", config, &collator, &collator_owned)) != 0) {
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
(void)wt_api->err_printf(wt_api, session,
Switch uses of wiredtiger_strerror() for WT_SESSION.strerror().
2015-03-20 17:46:54 -04:00
"collator configuration: %s",
session->strerror(session, ret));
Write the code to marshall/unmarshall to/from the cache structure (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.
2013-07-04 09:12:50 -04:00
return (ret);
}
/*! [WT_EXTENSION collator config] */
}
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE error message] */
/*
* If an underlying function fails, log the error and then return an
* error within WiredTiger's name space.
*/
if ((ret = data_source_cursor()) != 0) {
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
(void)wt_api->err_printf(wt_api,
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
session, "my_open_cursor: %s", data_source_error(ret));
return (WT_ERROR);
}
/*! [WT_DATA_SOURCE error message] */
Add examples to the WiredTiger extension methods for accessing the metadata.
2013-06-04 12:56:26 -04:00
{
/*! [WT_EXTENSION metadata insert] */
/*
* Insert a new WiredTiger metadata record.
*/
const char *key = "datasource_uri";
const char *value = "data source uri's record";
if ((ret = wt_api->metadata_insert(wt_api, session, key, value)) != 0) {
(void)wt_api->err_printf(wt_api, session,
Switch uses of wiredtiger_strerror() for WT_SESSION.strerror().
2015-03-20 17:46:54 -04:00
"%s: metadata insert: %s", key,
session->strerror(session, ret));
Add examples to the WiredTiger extension methods for accessing the metadata.
2013-06-04 12:56:26 -04:00
return (ret);
}
/*! [WT_EXTENSION metadata insert] */
}
{
/*! [WT_EXTENSION metadata remove] */
/*
* Remove a WiredTiger metadata record.
*/
const char *key = "datasource_uri";
if ((ret = wt_api->metadata_remove(wt_api, session, key)) != 0) {
(void)wt_api->err_printf(wt_api, session,
Switch uses of wiredtiger_strerror() for WT_SESSION.strerror().
2015-03-20 17:46:54 -04:00
"%s: metadata remove: %s", key,
session->strerror(session, ret));
Add examples to the WiredTiger extension methods for accessing the metadata.
2013-06-04 12:56:26 -04:00
return (ret);
}
/*! [WT_EXTENSION metadata remove] */
}
{
/*! [WT_EXTENSION metadata search] */
/*
Fix an example's comment.
2015-12-11 09:43:29 -05:00
* Search for a WiredTiger metadata record.
Add examples to the WiredTiger extension methods for accessing the metadata.
2013-06-04 12:56:26 -04:00
*/
const char *key = "datasource_uri";
Don't use const for strings returned in allocated memory.
2014-10-16 18:12:57 +11:00
char *value;
Add examples to the WiredTiger extension methods for accessing the metadata.
2013-06-04 12:56:26 -04:00
if ((ret =
wt_api->metadata_search(wt_api, session, key, &value)) != 0) {
(void)wt_api->err_printf(wt_api, session,
Switch uses of wiredtiger_strerror() for WT_SESSION.strerror().
2015-03-20 17:46:54 -04:00
"%s: metadata search: %s", key,
session->strerror(session, ret));
Add examples to the WiredTiger extension methods for accessing the metadata.
2013-06-04 12:56:26 -04:00
return (ret);
}
printf("metadata: %s has a value of %s\n", key, value);
/*! [WT_EXTENSION metadata search] */
}
{
/*! [WT_EXTENSION metadata update] */
/*
* Update a WiredTiger metadata record (insert it if it does not yet
* exist, update it if it does).
*/
const char *key = "datasource_uri";
const char *value = "data source uri's record";
if ((ret = wt_api->metadata_update(wt_api, session, key, value)) != 0) {
(void)wt_api->err_printf(wt_api, session,
Switch uses of wiredtiger_strerror() for WT_SESSION.strerror().
2015-03-20 17:46:54 -04:00
"%s: metadata update: %s", key,
session->strerror(session, ret));
Add examples to the WiredTiger extension methods for accessing the metadata.
2013-06-04 12:56:26 -04:00
return (ret);
}
/*! [WT_EXTENSION metadata update] */
}
Add some more structure to the data-source cursor-create example.
2013-06-10 09:33:26 -04:00
}
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
return (0);
}
/*! [WT_DATA_SOURCE rename] */
static int
my_rename(WT_DATA_SOURCE *dsrc, WT_SESSION *session,
Use an opaque type for config arguments passed to callbacks, rather than void *.
2013-04-18 16:51:20 +10:00
const char *uri, const char *newname, WT_CONFIG_ARG *config)
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE rename] */
{
/* Unused parameters */
(void)dsrc;
(void)session;
(void)uri;
(void)newname;
(void)config;
return (0);
}
/*! [WT_DATA_SOURCE salvage] */
static int
my_salvage(WT_DATA_SOURCE *dsrc, WT_SESSION *session,
Use an opaque type for config arguments passed to callbacks, rather than void *.
2013-04-18 16:51:20 +10:00
const char *uri, WT_CONFIG_ARG *config)
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE salvage] */
{
/* Unused parameters */
(void)dsrc;
(void)session;
(void)uri;
(void)config;
return (0);
}
/*! [WT_DATA_SOURCE truncate] */
static int
Use an opaque type for config arguments passed to callbacks, rather than void *.
2013-04-18 16:51:20 +10:00
my_truncate(WT_DATA_SOURCE *dsrc, WT_SESSION *session,
const char *uri, WT_CONFIG_ARG *config)
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE truncate] */
{
/* Unused parameters */
(void)dsrc;
(void)session;
(void)uri;
(void)config;
return (0);
}
Move data source truncate method into WT_DATA_SOURCE.
2013-08-08 20:05:38 +10:00
/*! [WT_DATA_SOURCE range truncate] */
static int
my_range_truncate(WT_DATA_SOURCE *dsrc, WT_SESSION *session,
WT_CURSOR *start, WT_CURSOR *stop)
/*! [WT_DATA_SOURCE range truncate] */
{
/* Unused parameters */
(void)dsrc;
(void)session;
(void)start;
(void)stop;
return (0);
}
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE verify] */
static int
Use an opaque type for config arguments passed to callbacks, rather than void *.
2013-04-18 16:51:20 +10:00
my_verify(WT_DATA_SOURCE *dsrc, WT_SESSION *session,
const char *uri, WT_CONFIG_ARG *config)
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE verify] */
{
/* Unused parameters */
(void)dsrc;
(void)session;
(void)uri;
(void)config;
return (0);
}
Add a WT_DATA_SOURCE method to support session.checkpoint, then drill 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.
2013-07-31 13:54:04 -04:00
/*! [WT_DATA_SOURCE checkpoint] */
static int
my_checkpoint(WT_DATA_SOURCE *dsrc, WT_SESSION *session, WT_CONFIG_ARG *config)
/*! [WT_DATA_SOURCE checkpoint] */
{
/* Unused parameters */
(void)dsrc;
(void)session;
(void)config;
return (0);
}
Add handle.terminate methods to WT_COLLATOR, WT_COMPRESSOR and 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.
2013-05-07 11:50:12 -04:00
/*! [WT_DATA_SOURCE terminate] */
static int
my_terminate(WT_DATA_SOURCE *dsrc, WT_SESSION *session)
/*! [WT_DATA_SOURCE terminate] */
{
/* Unused parameters */
(void)dsrc;
(void)session;
return (0);
}
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
int
main(void)
{
WT_CONNECTION *conn;
Transaction ID extension methods need a real session handle.
2013-06-11 09:17:11 +10:00
WT_SESSION *session;
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
int ret;
ret = wiredtiger_open(NULL, NULL, "create", &conn);
Transaction ID extension methods need a real session handle.
2013-06-11 09:17:11 +10:00
ret = conn->open_session(conn, NULL, NULL, &session);
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
my_data_source_init(conn);
Data source cleanup: fix some build warnings, exclude new function from the Java API, allow enough space in the wiredtiger_open cfg stack for a WIREDTIGER_CONFIG environment variable.
2013-04-12 11:01:12 +10:00
{
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
/*! [WT_DATA_SOURCE register] */
static WT_DATA_SOURCE my_dsrc = {
my_create,
my_compact,
my_drop,
my_open_cursor,
my_rename,
my_salvage,
my_truncate,
Move data source truncate method into WT_DATA_SOURCE.
2013-08-08 20:05:38 +10:00
my_range_truncate,
Add handle.terminate methods to WT_COLLATOR, WT_COMPRESSOR and 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.
2013-05-07 11:50:12 -04:00
my_verify,
Add a WT_DATA_SOURCE method to support session.checkpoint, then drill 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.
2013-07-31 13:54:04 -04:00
my_checkpoint,
Add handle.terminate methods to WT_COLLATOR, WT_COMPRESSOR and 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.
2013-05-07 11:50:12 -04:00
my_terminate
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
};
ret = conn->add_data_source(conn, "dsrc:", &my_dsrc, NULL);
/*! [WT_DATA_SOURCE register] */
Data source cleanup: fix some build warnings, exclude new function from the Java API, allow enough space in the wiredtiger_open cfg stack for a WIREDTIGER_CONFIG environment variable.
2013-04-12 11:01:12 +10:00
}
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
/*! [WT_DATA_SOURCE configure boolean] */
Enhance some wording and the examples.
2013-04-11 08:49:54 -04:00
/* my_boolean defaults to true. */
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
ret = conn->configure_method(conn,
Change WT_CONNECTION.configure_method() to do the same name translation as wiredtiger_config_validate(), that is, specify a method name using the concatentation of the public handle name, a period and a method name, rather than using our internal configuration string names. Move the WT_CONNECTION.configure_method() code into config/config_api.c.
2015-04-15 14:55:36 -04:00
"WT_SESSION.open_cursor", NULL, "my_boolean=true", "boolean", NULL);
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
/*! [WT_DATA_SOURCE configure boolean] */
/*! [WT_DATA_SOURCE configure integer] */
Enhance some wording and the examples.
2013-04-11 08:49:54 -04:00
/* my_integer defaults to 5. */
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
ret = conn->configure_method(conn,
Change WT_CONNECTION.configure_method() to do the same name translation as wiredtiger_config_validate(), that is, specify a method name using the concatentation of the public handle name, a period and a method name, rather than using our internal configuration string names. Move the WT_CONNECTION.configure_method() code into config/config_api.c.
2015-04-15 14:55:36 -04:00
"WT_SESSION.open_cursor", NULL, "my_integer=5", "int", NULL);
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
/*! [WT_DATA_SOURCE configure integer] */
/*! [WT_DATA_SOURCE configure string] */
Enhance some wording and the examples.
2013-04-11 08:49:54 -04:00
/* my_string defaults to "name". */
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
ret = conn->configure_method(conn,
Change WT_CONNECTION.configure_method() to do the same name translation as wiredtiger_config_validate(), that is, specify a method name using the concatentation of the public handle name, a period and a method name, rather than using our internal configuration string names. Move the WT_CONNECTION.configure_method() code into config/config_api.c.
2015-04-15 14:55:36 -04:00
"WT_SESSION.open_cursor", NULL, "my_string=name", "string", NULL);
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
/*! [WT_DATA_SOURCE configure string] */
/*! [WT_DATA_SOURCE configure list] */
Enhance some wording and the examples.
2013-04-11 08:49:54 -04:00
/* my_list defaults to "first" and "second". */
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
ret = conn->configure_method(conn,
Change WT_CONNECTION.configure_method() to do the same name translation as wiredtiger_config_validate(), that is, specify a method name using the concatentation of the public handle name, a period and a method name, rather than using our internal configuration string names. Move the WT_CONNECTION.configure_method() code into config/config_api.c.
2015-04-15 14:55:36 -04:00
"WT_SESSION.open_cursor",
Enhance some wording and the examples.
2013-04-11 08:49:54 -04:00
NULL, "my_list=[first, second]", "list", NULL);
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
/*! [WT_DATA_SOURCE configure list] */
/*! [WT_DATA_SOURCE configure integer with checking] */
/*
* Limit the number of devices to between 1 and 30; the default is 5.
*/
ret = conn->configure_method(conn,
Change WT_CONNECTION.configure_method() to do the same name translation as wiredtiger_config_validate(), that is, specify a method name using the concatentation of the public handle name, a period and a method name, rather than using our internal configuration string names. Move the WT_CONNECTION.configure_method() code into config/config_api.c.
2015-04-15 14:55:36 -04:00
"WT_SESSION.open_cursor",
NULL, "devices=5", "int", "min=1, max=30");
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
/*! [WT_DATA_SOURCE configure integer with checking] */
Enhance some wording and the examples.
2013-04-11 08:49:54 -04:00
/*! [WT_DATA_SOURCE configure string with checking] */
/*
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
* Limit the target string to one of /device, /home or /target; default
* to /home.
Enhance some wording and the examples.
2013-04-11 08:49:54 -04:00
*/
ret = conn->configure_method(conn,
Change WT_CONNECTION.configure_method() to do the same name translation as wiredtiger_config_validate(), that is, specify a method name using the concatentation of the public handle name, a period and a method name, rather than using our internal configuration string names. Move the WT_CONNECTION.configure_method() code into config/config_api.c.
2015-04-15 14:55:36 -04:00
"WT_SESSION.open_cursor", NULL, "target=/home", "string",
Simplify quoting in config string examples, now that quotes are not reqired for string values starting with slashes.
2013-05-08 16:29:19 +10:00
"choices=[/device, /home, /target]");
Enhance some wording and the examples.
2013-04-11 08:49:54 -04:00
/*! [WT_DATA_SOURCE configure string with checking] */
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
/*! [WT_DATA_SOURCE configure list with checking] */
/*
More work on data-source configuration support. 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.
2013-04-11 15:58:42 -04:00
* Limit the paths list to one or more of /device, /home, /mnt or
* /target; default to /mnt.
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
*/
ret = conn->configure_method(conn,
Change WT_CONNECTION.configure_method() to do the same name translation as wiredtiger_config_validate(), that is, specify a method name using the concatentation of the public handle name, a period and a method name, rather than using our internal configuration string names. Move the WT_CONNECTION.configure_method() code into config/config_api.c.
2015-04-15 14:55:36 -04:00
"WT_SESSION.open_cursor", NULL, "paths=[/mnt]", "list",
Simplify quoting in config string examples, now that quotes are not reqired for string values starting with slashes.
2013-05-08 16:29:19 +10:00
"choices=[/device, /home, /mnt, /target]");
Add documentation and examples for setting custom configuration strings. I'm doing it in the WT_DATA_SOURCE pages because that's the only part of the system that can currently use application-specified config strings.
2013-04-10 15:21:50 -04:00
/*! [WT_DATA_SOURCE configure list with checking] */
Add a new WT_EXTENSION_API method that returns the default session for 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).
2013-04-16 13:02:55 -04:00
/*! [WT_EXTENSION_API default_session] */
More changes to the extension API (this is only part-way there, but it 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.
2013-04-17 10:00:15 -04:00
(void)wt_api->msg_printf(wt_api, NULL, "configuration complete");
Add a new WT_EXTENSION_API method that returns the default session for 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).
2013-04-16 13:02:55 -04:00
/*! [WT_EXTENSION_API default_session] */
Add a new method WT_EXTENSION_API::config that takes a cfg[] and returns a configuration string's value. Push that method through the KVS code in test/format.
2013-04-10 13:58:34 -04:00
(void)conn->close(conn, NULL);
return (ret);
}
Reference in New Issue Copy Permalink