It's actually a good question David, I also heard of other database which has this requirement. In derby
users are not requied to shutdown the datbase before doing upgrade/ downgrade , I think is is to make Derby Zero-Admin database. Any changes to the logging system also have to handle
upgrade/downgrade issues.


Thanks
-suresht

David Van Couvering wrote:

Sorry, perhaps a dumb question here -- I'm still learning how Derby works. If someone wants to downgrade from revision N+1 to revision N, wouldn't they normally shut down the database prior to downgrade, in which case the data gets checkpointed and the log files wouldn't be needed?

Thanks,

David

Mike Matrigali wrote:

I am looking at committing this.  The changes look good to me, but I
believe there are upgrade issues to handle.

For a hard upgrade either new or old databases are fine.
For a soft upgrade I think there is a problem if the db generates enough
log files to start using the new bits, and then the software is reverted
to before the fix.

Seems like using the bits needs to be somehow only enabled for hard
upgrade.  It would be best if it was controlled just by hard upgrade,
but if that is not possible then just doing it for databases created
since this version would also work - but still leave problems with old
hard upgraded databases.

I have reviewed the code and am running tests.  I plan on committing
this part of the fix and let you address upgrade issues with a follow on
patch.

Suresh Thalamati wrote:





Reply via email to