範囲削除でIDが最大値のLumpが削除できない

[sile]

現状のdelete_rangeのインターフェースではdelete_range(LumpId::new(0), LumpId::new(u128::MAX)のように指定してもu128::MAXは削除対象に含まれないため、最大値のIDを有するLumpをdelete_rangeで削除する方法がない。

Boundを引数に受け取るように変更する必要があるかもしれない（あるいは、end部分の扱いをinclusiveにするか）。

[sile]

対応方針(案)メモ

ストレージフォーマットの互換性を崩さない方式:

• delete_rangeのstartおよびendの型をBoundにした版のメソッドを追加
• ただし、内部的にはdelete_rangeに変形して処理する
  • 例外として Bound::Unbound ないし Bound::Included(最大ID) がendに指定された場合には、追加でdelete(最大ID)を内部的に発行する
• cannylsのバージョンをv1.0.0に上げるタイミングに合わせて、外部にはBound版のdelete_rangeのみを提供するようにする

代替案

• (a) DELETE_RANGEレコードのendの扱いをinclusiveにする
  • ストレージフォーマットの互換性が崩れるので、フォーマットのメジャーバージョンを上げる必要があり影響が大きい
• (b) DELETE_RANGE_INCLUSIVE的なレコードを新設する
  • 似たようなレコードが複数できることになってしまう
  • 最大IDがendで指定されることはごく稀だと思われるので、そのためだけに追加するのはやりすぎ感
  • 冒頭に記載した方式の採用後に、DELETE_RANGE_INCLUSIVEレコードを追加することも可能
    • ただし、DELETE_RANGE_INCLUSIVEを一度導入してしまうと、もう削除はできない（ので慎重に検討したい）

欠点

• アトミック性が崩れる
  • delete_rangeと内部的に生成されたdeleteのレコード追記の間でプロセスがクラッシュすると、前者だけが反映された状態になってしまう

[sile]

https://github.com/frugalos/cannyls/issues/7#issuecomment-435043169 は 欠点 が気になるので、代替案の (b) 方式の方が良いかもしれない。 かつ、現状の使用状況を仮定して、cannyls-v1のリリースタイミングで、旧DELETE_RANGEレコードは削除してしまう（削除が厳しいなら、レコード読み込み部分に旧DELETE_RANGEを検出したら、新DELETE_RANGEに変換する処理を入れても良いかもしれない）。