You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Glen Mazza <gl...@gmail.com> on 2014/08/21 18:42:38 UTC
[FAILED][CODE FREEZE: On]Re: [VOTE] Release Apache Roller 5.1
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
> ##
>
> Formatting section on preference | settings
>
> Not sure on this now, maybe needs to be removed from WeblogConfig.jsp as
> bean.defaultPluginsArray has been removed.
>
> <s:if test="!pluginsList.isEmpty">
> <tr>
> <td class="label"><s:text name="websiteSettings.label1" /> <br
> /><s:text name="websiteSettings.label2" /></td>
> <td class="field">
> <s:checkboxlist theme="roller" list="pluginsList"
> name="bean.defaultPluginsArray" listKey="name" listValue="name" />
>
> </td>
> <td class="description"><%-- <s:text
> name="websiteSettings.tip." /> --%></td>
> </tr>
> </s:if>
> <s:else>
> <s:hidden name="defaultPlugins" />
> </s:else>
>
My error, I should not have removed defaultPlugins from the Weblog
class, in my email of July 23rd I recommended its removal without
realizing it was indeed configurable at the blog level:
8.) defaultplugins: Always null, no place to configure at the
blog-level, as with #2 above, perhaps best to let the blog admin
configure this for all bloggers in the roller-custom.properties file.
I'll put this back in and come up with another RC3 today.
Regards,
Glen
Re: [FAILED][CODE FREEZE: On]Re: [VOTE] Release Apache Roller 5.1
Posted by Glen Mazza <gl...@gmail.com>.
On 08/21/2014 02:08 PM, Dave wrote:
> On Thu, Aug 21, 2014 at 12:42 PM, Glen Mazza<gl...@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
Re: [FAILED][CODE FREEZE: On]Re: [VOTE] Release Apache Roller 5.1
Posted by Dave <sn...@gmail.com>.
On Thu, Aug 21, 2014 at 12:42 PM, Glen Mazza <gl...@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.
Possible solutions:
* In the upgrade docs, tell people not to run the script manually
* 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)
* Provide a command line program that does runs the migration and ignores
errors
- Dave