Discussions
Categories
- 196.8K All Categories
- 2.2K Data
- 239 Big Data Appliance
- 1.9K Data Science
- 450.3K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 544 SQLcl
- 4K SQL Developer Data Modeler
- 187K SQL & PL/SQL
- 21.3K SQL Developer
- 295.8K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.5K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 439 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
bulk loading B-tree with unsigned long keys does not work.

Hi,
I am trying to bulk load and read from BDB-Btree with "unsigned long int" keys.
When I make some minor modifications in the Bulkexample code, the tree is not being generated correctly.
What I have done: I changed the key type as u_int32_t and changed the variables type in compare_int function as well.
It seemed to me the problem is about alignment.
Then, I put my key data in byte array and used marshalling/unmarshalling techniques, still I cannot read data sorted by key :(
The code has something like the below
u_int32_t keyvalue=rnd->nextUniformUnsignedLong(); // rnd is my random generator
uint32_t sizeOfKey = sizeof(u_int32_t);
uint8_t *bufkey = new uint8_t[sizeOfKey]; // allocate a buffer area.
uint8_t *it = bufkey; // pointer variable to iterate over the buffer.
memcpy(it, &keyvalue, sizeOfKey);
uint8_t *bufdata = new uint8_t[DATALEN]; // allocate a buffer area.
it = bufdata; // pointer variable to iterate over the buffer.
memcpy(it, &(data_val->id), sizeof(int));
it += sizeof(int);
memcpy(it, data_val->str, STRLEN);
...
if (ptrkd->append(bufkey, sizeOfKey,
bufdata, DATALEN) == false)
throwException(dbenv,
txnp, EXIT_FAILURE,...)
In the compare function:
uint32_t sizeOfKey = sizeof(u_int32_t); //uint_fast32_t
uint8_t *it = (uint8_t *)a->get_data(); // allocate a total buffer area. Write explicit size for the array, do not use sizeof()
memcpy(&ai, it, sizeOfKey);
it=nullptr;
it = (uint8_t*) b->get_data(); // allocate a total buffer area. Write explicit size for the array, do not use sizeof()
memcpy(&bi, it, sizeOfKey);
// memcpy(&ai, a->get_data(), sizeof(int));
// memcpy(&bi, b->get_data(), sizeof(int));
return (ai - bi);
Similiar problems occur when I try to load b-tree with double keys..It does not sort correctly.
Thanks for the help. Good holidays..
Answers
-
Is this a 32-bit or 64-bit compiled program? The "long" data type changes from 32-bit to 64-bit depending on how you compile, so it is best never use the C data type names any more. Use the system unambiguous types, like uint32_t and uint64_t, etc.
I see some use of uint32_t in your example code, but you are still saying "long" in your description. You are also assuming "int" is 32-bit, which is less of a problem, but it is a bad assumption to make.
The "double" type in C is always 64-bit and is not the same size as a "long", depending on what I mentioned above. Use the unambiguous types provided by your compiler/OS headers.
Based on your function name, nextUniformUnsignedLong(), I do not know what size data I can expect from that (32-bit or 64-bit)?
Since BDB stores keys as byte arrays (and uses memcpy), Little Endian keys derived from native types will not sort correctly without your own comparison function. Alternatively (and easier), you can just byte-swap the key before storing it or using it for a lookup. My preference, it saves having to mess around with custom compare functions and such.
I have been using 32-bit and 64-bit keys in my BDBs for over a decade.