On Friday 19 September 2003 15:03, Dennis Gearon wrote:
> IPU, in place updates.
> --------------------------
>
> 1/ Put a version numbers on each record represented by a byte/word sized
> number from a three version number list kept by the table header. This
> would then only involve one more byte per record. This version number
> list needs to be the VERY first item in the table header. The lowest
> ordered byte of the first word of the version number list contains the
> size of the words in bytes. The version number list's version number is
> the second word in the structure. ( we shouldn't run out of 2^16, 2^32,
> 2^64, 2^128, or 2^256 versions list versions ).
[snip consideration of the issues involved in migrating the on-disk formats]
Well, you could get away with one bit if you had to. You're only allowed two
versions - the old and the new. Saying that upgrading a half-upgraded
database is disallowed doesn't strike me as unreasonable.
But, the disk format is only the first step. If I'm upgrading in place then I
need to be sure that the behaviour of the system isn't going to change,
because I can't undo (otherwise, I'd just dump/restore).
So - let's say inheritence changes so that primary keys are inherited. You're
going to be in a situation where you need to manage both old and new
behaviour at the same time. In addition, you're going to need some
translation function that can update old schema details to match new schema
constraints.
OK - maybe we say changes like that can't be supported, in which case the
developers need to be careful about what changes are planned/implemented at
what points. Non-trivial stuff.
--
Richard Huxton
Archonet Ltd