On 08/21/2014 02:08 PM, Dave wrote:
On Thu, Aug 21, 2014 at 12:42 PM, Glen Mazza<glen.ma...@gmail.com> wrote:
On 08/21/2014 05:39 AM, Greg Huber wrote:
Glen,
On upgrading/testing.
##
One of my databases failed on this statement on the upgrade. The index did
not exist.
ALTER TABLE bookmark_folder DROP INDEX folder_namefolderid_uq;
Its does mention it may not exist.
Hi Greg, yes, I put a change in the code for dropping of nonexistent
indexes to be a non-fatal upgrade error, seeing that we don't need to fail
if we're trying to delete something that already doesn't exist. Some
roller installs have indexes that others don't, and I just want the upgrade
to proceed in those cases, rather than leave people with a half-completed
database.
http://svn.apache.org/viewvc/roller/trunk/app/src/main/
java/org/apache/roller/weblogger/business/startup/SQLScriptRunner.java?r1=
1580425&r2=1613234&diff_format=h
The problem with that fix is that many sys admins prefer (that was my first
inclination and Greg's too) to run the database script "manually" instead
of letting Roller run the script. When you run the script manually, that
error causes the script to fail.
OK, I just saw the relevant section in our Install Guide (Section 10.2),
to me manual process meant the DBA ran the statements one-by-one before
going on to the next, not that they would run a single SQL script
without looking at or modifying its contents, as the latter process
wouldn't give them much advantage over the automated process. We've
already commented in the migration script that this index may not exist
and hence manual upgraders may not wish to run the statement:
-- If you run this script manually (i.e. you are doing
installation.type=manual)
-- them you may need to comment out this next statement, this index does
not
-- exist in all Roller systems:
alter table bookmark_folder drop index folder_namefolderid_uq;
Possible solutions:
* In the upgrade docs, tell people not to run the script manually
That's too strong. I just need to update the section saying that the
migration script may not be runnable as a whole as some databases throw
an error when one attempts to delete an index or foreign key that does
not already exist, something that the automated process takes care of
automatically. Therefore, manual upgraders may need to run the upgrade
statements one-by-one rather than the script as a whole, or comment out
drop index or foreign key statements that they already know don't exist.
I'll get that done.
* In the upgrade docs, tell people that want to run manually they should
use a "continue on error" appropriate for their database (on MySQL this is
the --force option)
Possible, but continue on error is too dangerous because you need to
know what the error is. Dropping something that doesn't already exist
is normally survivable, but other types of errors you do want the
database script to halt on. Manual updaters, i.e., those leery of
relying on our automated process, would probably also be equally leery
of "continue on error".
Glen
