head 1.2; access; symbols RPM_4_2_1:1.1.1.5 RPM_4_2:1.1.1.5 RPM_4_1_1:1.1.1.5 RPM_4_1:1.1.1.4 RPM_4_0_5:1.1.1.3 RPM_4_0_4:1.1.1.2 RPM_4_0_3:1.1.1.1 RPM:1.1.1; locks; strict; comment @# @; 1.2 date 2008.01.02.09.56.09; author rse; state dead; branches; next 1.1; commitid z4cpSiAhOCXk5PLs; 1.1 date 2001.07.23.20.45.38; author rse; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 2001.07.23.20.45.38; author rse; state Exp; branches; next 1.1.1.2; 1.1.1.2 date 2002.01.08.00.30.13; author rse; state Exp; branches; next 1.1.1.3; 1.1.1.3 date 2003.01.18.13.49.04; author rse; state Exp; branches; next 1.1.1.4; 1.1.1.4 date 2001.05.13.19.58.47; author rse; state Exp; branches; next 1.1.1.5; 1.1.1.5 date 2003.01.18.14.05.00; author rse; state Exp; branches; next ; desc @@ 1.2 log @remove the ancient RPM 4.2.1 source tree copy @ text @ Berkeley DB Reference Guide: Release 3.1: DB->put

Berkeley DB Reference Guide:
Upgrading Berkeley DB Applications

 PrevRefNext

Release 3.1: DB->put

For the Queue and Recno access methods, when the DB_APPEND flag is specified to the DB->put interface, the allocated record number is returned to the application in the key DBT argument. In previous releases of Berkeley DB, this DBT structure did not follow the usual DBT conventions. For example, it was not possible to cause Berkeley DB to allocate space for the returned record number. Rather, it was always assumed that the data field of the key structure referred to memory that could be used as storage for a db_recno_t type.

As of the Berkeley DB 3.1.0 release, the key structure behaves as described in the DBT C++/Java class or C structure documentation.

Applications which are using the DB_APPEND flag for Queue and Recno access method databases will require a change to upgrade to the Berkeley DB 3.1 releases. The simplest change is likely to be to add the DB_DBT_USERMEM flag to the key structure. For example, code that appears as follows: 

DBT key;
db_recno_t recno;


memset(&key, 0, sizeof(DBT));
key.data = &recno;
key.size = sizeof(recno);
DB->put(DB, NULL, &key, &data, DB_APPEND);
printf("new record number is %lu\n", (u_long)recno);

would be changed to: 

DBT key;
db_recno_t recno;


memset(&key, 0, sizeof(DBT));
key.data = &recno;
key.ulen = sizeof(recno);
key.flags = DB_DBT_USERMEM;
DB->put(DB, NULL, &key, &data, DB_APPEND);
printf("new record number is %lu\n", (u_long)recno);

Note that the ulen field is now set as well as the flag value. An alternative change would be: 

DBT key;
db_recno_t recno;


memset(&key, 0, sizeof(DBT));
DB->put(DB, NULL, &key, &data, DB_APPEND);
recno = *(db_recno_t *)key->data;
printf("new record number is %lu\n", (u_long)recno);

PrevRefNext

Copyright Sleepycat Software @ 1.1 log @Initial revision @ text @d1 1 a1 1 @ 1.1.1.1 log @Import: RPM 4.0.3 @ text @@ 1.1.1.2 log @Import: RPM 4.0.4 @ text @d1 1 a1 1 @ 1.1.1.3 log @Import: RPM 4.0.5 @ text @d2 1 a2 1 a3 1 d19 3 a21 3 number is returned to the application in the key DBT argument. In previous releases of Berkeley DB, this DBT structure did not follow the usual DBT conventions. For example, it was d27 1 a27 1 described in the DBT C++/Java class or C structure documentation. d31 1 a31 1 DB_DBT_USERMEM flag to the key structure. For example, @ 1.1.1.4 log @Import: RPM 4.1 @ text @d2 1 a2 1 d4 1 d20 3 a22 3 number is returned to the application in the key DBT argument. In previous releases of Berkeley DB, this DBT structure did not follow the usual DBT conventions. For example, it was d28 1 a28 1 described in the DBT C++/Java class or C structure documentation. d32 1 a32 1 DB_DBT_USERMEM flag to the key structure. For example, @ 1.1.1.5 log @Import: RPM 4.1.1 @ text @d2 1 a2 1 a3 1 d19 3 a21 3 number is returned to the application in the key DBT argument. In previous releases of Berkeley DB, this DBT structure did not follow the usual DBT conventions. For example, it was d27 1 a27 1 described in the DBT C++/Java class or C structure documentation. d31 1 a31 1 DB_DBT_USERMEM flag to the key structure. For example, @