Renaming of an item throughout its history as a correction.

[sageserpent-open]

If it turns out that a set of events was booked into the system that all refer to some item via an id 'Foo', but it is found out later that the item should have been called 'Bar' all along, we need a way to conveniently rename 'Foo' to 'Bar' without forcing client code to have to rewrite all of the events to refer to the correct item.

That way, a single rename revision implies all of the necessary event adjustments. For now, let's treat this as being a full revision in its own right, rather than as part of a larger revision.

Hmm. OTOH, we could generate a map of events for a revision instead as the result of a renaming - this map could then be further amended if other events or annulments need to be added into a revision.

[sageserpent-open]

Following the discussion in issue #31, this story has an extra wrinkle in that a lower time bound can be specified to allow the rewriting of only a portion of an item's history. In fact, having a mandatory lower time bound might be a good idea - what should happen if there are several items with the same id and lower-bound type that exist for a while, get annihilated, are then reintroduced and so on?

I wouldn't expect a rename to apply across the board, rather I'd expect just one of these items to be renamed. The annihilation of an item serves as a natural cutoff as we go later in time for the renaming, but how do we pick out the item. If the lower time bound is mandatory, we can use that pick out the item that either exists at that time, or comes earliest following that time (or consider it a precondition failure if no such item exists at that point).

Now, given that this story never introduces an actual renaming event on to the timeline, it means that the lower bound time has no effect other than to select the subsequent events to be corrected - no new event will be added. It follows that there is a kind of consistency in allowing a lower time bound that comes before the first event on an item's timeline - again, it would not define an event in its own right. So we'd never get a precondition failure. Hmm....

[sageserpent-open]

Another point - suppose I rename either via this story or issue #31, then apply a second rename at an earlier point in time via either of the two mechanisms? I'd imagine that both renames should then take place, so the corrections from the second rename only propagate up the item's timeline as far as the first rename coming at a later point in time.

[sageserpent-open]

Something that has been left unsaid (but is implied by both the prior comments here and in #31) is that the lower time bound should not cause item renaming prior to that time - so if there is an existing run of events the pertain to an id, say "A", and then "A" is renamed to "B" for all t >= LB, then this will create a new history where there are two independent items, "A" (which exists before LB) and "B" (which comes into effect at some point t >= LB).

This has a bearing on the previous comment - what is described there is a two-step process of splitting an item's events - we start with an "X", rename it to "B" at some T1 (thus giving us an "X" and a "B") and then introduce an earlier rename to "A" at T2 < T1, so we end up with potentially three items, "X" defined before T2, "A" from some T >= T2 < T1 and "B" from T >= T1.