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.16; 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.2: Logically renumbering records

Berkeley DB Reference Guide:
Upgrading Berkeley DB Applications

 PrevRefNext

Release 3.2: Logically renumbering records

In the Berkeley DB 3.2 release, cursor adjustment semantics changed for Recno databases with mutable record numbers. Before the 3.2 release, cursors were adjusted to point to the previous or next record at the time the record to which the cursor referred was deleted. This could lead to unexpected behaviors. For example, two cursors referring to sequential records that were both deleted would lose their relationship to each other and would refer to the same position in the database instead of their original sequential relationship. There were also command sequences that would have unexpected results. For example, DB_AFTER and DB_BEFORE cursor put operations, using a cursor previously used to delete an item, would perform the put relative to the cursor's adjusted position and not its original position.

In the Berkeley DB 3.2 release, cursors maintain their position in the tree regardless of deletion operations using the cursor. Applications that perform database operations, using cursors previously used to delete entries in Recno databases with mutable record numbers, should be evaluated to ensure that the new semantics do not cause application failure.

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 @ 1.1.1.4 log @Import: RPM 4.1 @ text @d2 1 a2 1 d4 1 @ 1.1.1.5 log @Import: RPM 4.1.1 @ text @d2 1 a2 1 a3 1 @