On 4/3/06, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
Right... In past, things like metadata queries or changes to them are written and tested well because it is more difficult to change them and there is no upgrade support for maintenance and point-releases. Similar issue with system schema changes or changing of system routines. Current upgrade mechanisms only works between major_minor release versions. Same as metadata.
If I declared a column to be not null in one of new system tables I added, there is no way I could change that in next maintenance version and have upgrade support that change. Adding or changing of system routines also have this issue. Should we try to "fix" all these in DERBY-1107 or is metadata case special?
Satheesh Bandaram <[EMAIL PROTECTED]> writes:
> This seems like a good problem to have?
Yes, as long as we actually fix a bug and don't introduce a new
one. But we don't write bugs, do we? :) Adding a version number to the
query name could help us out of that situation.
Right... In past, things like metadata queries or changes to them are written and tested well because it is more difficult to change them and there is no upgrade support for maintenance and point-releases. Similar issue with system schema changes or changing of system routines. Current upgrade mechanisms only works between major_minor release versions. Same as metadata.
If I declared a column to be not null in one of new system tables I added, there is no way I could change that in next maintenance version and have upgrade support that change. Adding or changing of system routines also have this issue. Should we try to "fix" all these in DERBY-1107 or is metadata case special?
--
Knut Anders
Thanks for your work on this... I think we should convert your original write up on metadata handling into a Wiki and try to update as the design changes.
Satheesh
