Colliding pages can be resolved underneath us
The potential problem
col123is a CollidingPage that collides with 0123p07.
- manager removes 0123p07:
- either by discarding the entire paper 0123
- or with the surgical removal of 0123p7
- manager double-clicks on the
- The Collision dialog appears? or a crash? or ...?
I've not checked but I'm pessimistic that something goes wrong.
A. The subroutine that discards pages needs to iterate over all CollidingPages and deal with them.
B. Workarounds happen in the Manager UI.
C. We remove the CollidingPages Table and concept of a CollidingPage as a state. Colliding pages happen on transactions, they are not states in the DB.
A, B sound like adding code whereas C sounds like deleting code. I'm leaning toward C.
When you try to map an Unknown to a Tpage, its possible you could be making a collision (note this is true right now and we have "special code" to deal with it). Instead of doing something, the API should just fail with a "Collision" error. And we (manager client) can take several options using existing API:
unk123to p. 7 of 0123.
unk123into an ExtraPage (keeping both).
- similar, but make
0123p07into an ExtraPage and
unk123into TPage p. 7 of 0123. (not sure this is so useful, but it is symmetric).
- do nothing:
unk123stays as a UnknownPage.