Hi Howard,
I've now switched the database to use MDB_DUPSORT and found what seems to be another issue to do with invalid data being returned after mdb_cursor_del. The following code shows the behaviour against a database that I can provide you with if you need:
rc = mdb_cursor_open(txn, dbi, &cursor); char seek[] = "ku.oc.repmulp\t"; key.mv_size = sizeof(seek); key.mv_data = &seek; mdb_cursor_get(cursor, &key, &data, MDB_SET_RANGE); for( i = 0; i < 15; i++ ) { mdb_cursor_del( cursor, MDB_NODUPDATA ); data.mv_size = 0; key.mv_size = 0; mdb_cursor_get( cursor, &key, &data, //MDB_NEXT MDB_GET_CURRENT );
if( key.mv_size == 0 ) printf("WARNING 0 SIZE KEY\n"); else printf("KEY OK: %d: %.*s\n", key.mv_size, key.mv_size, key.mv_data); if( data.mv_size == 0 ) printf("WARNING 0 SIZE DATA\n"); else printf("DATA OK: %d: %.*s\n", data.mv_size, data.mv_size, data.mv_data); } mdb_txn_abort(txn);
If you run as-is it seems that if the cursor points at a record with multiple entries, the data is not updated. If however the mdb_cursor_del line is commented and mdb_cursor_get changed to use MDB_NEXT the output is as expected with multiple entries. Here is sample output with get-only:
KEY OK: 16: ku.oc.repmulp MX DATA OK: 40: 4160598 300 0 primary.mail.plumper.co.uk KEY OK: 16: ku.oc.repmulp MX DATA OK: 37: 4160598 300 10 cerebellum.david14.com KEY OK: 16: ku.oc.repmulp MX DATA OK: 46: 4160598 300 20 secondary-mail.mailhoster.co.uk KEY OK: 16: ku.oc.repmulp NS DATA OK: 30: 4160598 300 ns1.xcalibre.co.uk KEY OK: 16: ku.oc.repmulp NS DATA OK: 30: 4160598 300 ns2.xcalibre.co.uk KEY OK: 21: ku.oc.repmulp.05pot A DATA OK: 29: 4160598 86400 212.159.180.202 KEY OK: 22: ku.oc.repmulp.05pot MX DATA OK: 40: 4160598 300 0 primary.mail.plumper.co.uk KEY OK: 22: ku.oc.repmulp.05pot MX DATA OK: 37: 4160598 300 10 cerebellum.david14.com KEY OK: 22: ku.oc.repmulp.05pot MX DATA OK: 46: 4160598 300 20 secondary-mail.mailhoster.co.uk
And here with mdb_cursor_del: KEY OK: 16: ku.oc.repmulp MX WARNING 0 SIZE DATA KEY OK: 16: ku.oc.repmulp NS WARNING 0 SIZE DATA KEY OK: 21: ku.oc.repmulp.05pot A DATA OK: 29: 4160598 86400 212.159.180.202 KEY OK: 22: ku.oc.repmulp.05pot MX WARNING 0 SIZE DATA KEY OK: 25: ku.oc.repmulp.05pot.www A DATA OK: 29: 4160598 86400 212.159.180.202 KEY OK: 20: ku.oc.repmulp.3pop A DATA OK: 29: 4160598 86400 212.159.180.202
Behaviour seems to be the same regardless of whether I use MDB_NODUPDATA or 0 as the mdb_cursor_del flag (ie 0 length data returned and all duplicate entries deleted)
Thanks,
Mark