github.com/zuoyebang/bitalostable@v1.0.1-0.20240229032404-e3b99a834294/testdata/iterator_next_prev (about)

     1  build ext1
     2  merge a 1
     3  set c 2
     4  ----
     5  
     6  ingest ext1
     7  ----
     8  6:
     9    000004:[a#1,MERGE-c#1,SET]
    10  
    11  build ext2
    12  del-range b c
    13  ----
    14  
    15  ingest ext2
    16  ----
    17  0.0:
    18    000005:[b#2,RANGEDEL-c#72057594037927935,RANGEDEL]
    19  6:
    20    000004:[a#1,MERGE-c#1,SET]
    21  
    22  # Regression test for a bug where range tombstones were not properly
    23  # ignored by Iterator.prevUserKey when switching from forward to
    24  # reverse iteration. In the forward direction, the Iterator sees the
    25  # keys:
    26  #
    27  #   a#1,MERGE
    28  #   c#1,SET
    29  #
    30  # Due to the synthetic boundary key generated for sstable 5, in the
    31  # reverse direction Iterator sees the keys:
    32  #
    33  #   c#1,SET
    34  #   b#2,RANGEDEL
    35  #   a#1,MERGE
    36  #
    37  # Normally the record b#2,RANGEDEL is skipped by Iterator during
    38  # iteration, but logic to do so was missing from Iterator.prevUserKey.
    39  # The result was that prev could return the same key that iterator was
    40  # currently pointed at.
    41  
    42  iter
    43  first
    44  prev
    45  ----
    46  a:1
    47  .
    48  
    49  reset
    50  ----
    51  
    52  build ext1
    53  set t 1
    54  merge z 2
    55  ----
    56  
    57  ingest ext1
    58  ----
    59  6:
    60    000004:[t#1,SET-z#1,MERGE]
    61  
    62  build ext2
    63  del-range x y
    64  ----
    65  
    66  ingest ext2
    67  ----
    68  0.0:
    69    000005:[x#2,RANGEDEL-y#72057594037927935,RANGEDEL]
    70  6:
    71    000004:[t#1,SET-z#1,MERGE]
    72  
    73  # Regression test for a bug where range tombstones were not properly
    74  # ignored by Iterator.nextUserKey when switching from reverse to
    75  # forward iteration. In the reverse direction, the Iterator sees the
    76  # keys:
    77  #
    78  #   z#1,MERGE
    79  #   t#1,SET
    80  #
    81  # Due to the synthetic boundary key generated for sstable 5, in the
    82  # forward direction Iterator sees the keys:
    83  #
    84  #   t#1,SET
    85  #   y#72057594037927935,RANGEDEL
    86  #   z#1,MERGE
    87  #
    88  # Normally the record y#72057594037927935,RANGEDEL is skipped by
    89  # Iterator during iteration, but logic to do so was missing from
    90  # Iterator.nextUserKey. The result was that next could return the same
    91  # key that iterator was currently pointed at.
    92  
    93  iter
    94  last
    95  next
    96  ----
    97  z:2
    98  .
    99  
   100  # Verify that switching from reverse iteration to forward iteration
   101  # properly skips over range tombstones at the start of forward
   102  # iteration.
   103  
   104  reset
   105  ----
   106  
   107  build ext1
   108  set e e
   109  ----
   110  
   111  ingest ext1
   112  ----
   113  6:
   114    000004:[e#1,SET-e#1,SET]
   115  
   116  build ext2
   117  set b b
   118  del-range c d
   119  ----
   120  
   121  ingest ext2
   122  ----
   123  6:
   124    000005:[b#2,SET-d#72057594037927935,RANGEDEL]
   125    000004:[e#1,SET-e#1,SET]
   126  
   127  # The scenario requires iteration at a snapshot. The "last" operation
   128  # will exhaust the mergingIter looking backwards for visible
   129  # records. The subsequent "next" will seek-ge(lower) which will skip
   130  # over the "b" record and find the boundary key due to the range
   131  # deletion sentinel.
   132  
   133  iter seq=2
   134  set-bounds lower=c upper=f
   135  last
   136  next
   137  ----
   138  .
   139  e:e
   140  .
   141  
   142  # Test that the cloned iterator sees all the keys.
   143  iter
   144  set-bounds lower=a upper=f
   145  first
   146  next
   147  next
   148  clone
   149  seek-ge a
   150  next
   151  next
   152  ----
   153  .
   154  b:b
   155  e:e
   156  .
   157  .
   158  b:b
   159  e:e
   160  .
   161  
   162  # Test that the cloned iterator respects the original bounds.
   163  iter
   164  set-bounds lower=a upper=d
   165  first
   166  next
   167  clone
   168  seek-ge a
   169  next
   170  ----
   171  .
   172  b:b
   173  .
   174  .
   175  b:b
   176  .
   177  
   178  # Test that a cloned iterator set with new bounds, respects the new bounds and
   179  # options.
   180  iter
   181  set-bounds lower=a upper=d
   182  first
   183  next
   184  clone lower=a upper=z key-types=both
   185  seek-ge a
   186  next
   187  ----
   188  .
   189  b:b
   190  .
   191  .
   192  b: (b, .)
   193  e: (e, .)
   194  
   195  # Test that the cloned iterator respects the seq num.
   196  iter seq=2
   197  set-bounds lower=a upper=f
   198  first
   199  next
   200  clone
   201  last
   202  prev
   203  ----
   204  .
   205  e:e
   206  .
   207  .
   208  e:e
   209  .
   210  
   211  # Verify that switching from forward iteration to reverse iteration
   212  # properly skips over range tombstones at the end of reverse
   213  # iteration.
   214  
   215  reset
   216  ----
   217  
   218  build ext1
   219  merge a a
   220  ----
   221  
   222  ingest ext1
   223  ----
   224  6:
   225    000004:[a#1,MERGE-a#1,MERGE]
   226  
   227  build ext2
   228  set e e
   229  del-range c d
   230  ----
   231  
   232  ingest ext2
   233  ----
   234  6:
   235    000004:[a#1,MERGE-a#1,MERGE]
   236    000005:[c#2,RANGEDEL-e#2,SET]
   237  
   238  iter seq=2
   239  set-bounds lower=a upper=e
   240  first
   241  prev
   242  ----
   243  .
   244  a:a
   245  .
   246  
   247  reset
   248  ----
   249  
   250  # Test demonstrating inadvertent exposure of ordering effects of the
   251  # InternalKeyKind numbering. We build an sst with a (del/singledel, set) pair
   252  # for two user keys. When ingested, all 4 keys have the same seqnum. The set
   253  # overrides the del, and the singedel overrides the set.
   254  #
   255  # The test input setup looks peculiar because the build uses an indexed batch,
   256  # and iterates over it to write to the sst, so we need to place the set after
   257  # the del, and the singledel after the set in order for the batch ordering to
   258  # be one that is suitable for feeding into the sstable writer. All 4 keys are
   259  # being written to the sst (notice the bounds in the ingest).
   260  
   261  build ext1
   262  del a
   263  set a 1
   264  set b 2
   265  singledel b
   266  ----
   267  
   268  ingest ext1
   269  ----
   270  6:
   271    000004:[a#1,SET-b#1,SET]
   272  
   273  iter
   274  first
   275  next
   276  ----
   277  a:1
   278  .