[
https://issues.apache.org/jira/browse/VCL-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295423#comment-14295423
]
ASF subversion and git services commented on VCL-764:
-----------------------------------------------------
Commit 1655394 from [~arkurth] in branch 'vcl/trunk'
[ https://svn.apache.org/r1655394 ]
VCL-764
In vcl.sql and update-vcl.sql:
Changed default value of computer.predictivemoduleid from 1 to 9. Module 1 is
not by default a predictive loading module. Module 9 is "level 2".
Changed default value of image.basedoffrevisionid from 0 to 1 (noimage).
Cleaned up connectmethod names and descriptions. These are shown to end users
and should be formatted consistently.
Removed constraints:
image.basedoffrevisionid
serverrequest.serverprofileid
sublog.blockRequestid
In update-vcl.sql:
Added PrintMessage procedure for debugging.
Improved DropExistingConstraints procedure to make sure
information_schema.KEY_COLUMN.REFERENCED_TABLE_NAME is not null. It's possible
to have multiple entries which map a table and row. Only the entries with a
REFERENCED_TABLE_NAME value represent actual constraints.
Added an exception handler in AddConstraintIfNotExists. If a constraint can't
be added, the update would exit immediately. It now continues.
Added command to change blockRequest.admingroupid to a smallint(5) to match
usergroup.id column. This is already correct in vcl.sql.
Added commands to change computerloadflow.computerloadstateid and nextstateid
to unsigned to match computerloadstate.id.
Updated natlog table definition to match vcl.sql.
Changed capitalization of user.sshpublickeys to match vcl.conf and the backend
code.
Fixed problem where duplicate entries were inserted into connectmethodport if
the original connectmethod.protocol value was an empty string.
Added several constraints to match vcl.sql.
> Database changes for VCL 2.4
> ----------------------------
>
> Key: VCL-764
> URL: https://issues.apache.org/jira/browse/VCL-764
> Project: VCL
> Issue Type: Improvement
> Components: database
> Affects Versions: 2.3.2
> Reporter: Andy Kurth
> Fix For: 2.4
>
>
> This is a catchall issue to track database changes for VCL 2.4 which aren't
> directly related to another issue.
> We really need to rework the database update process when upgrading VCL
> versions. update-vcl.sql is difficult to manage and keep in sync with
> vcl.sql. A single Perl script could be written which could be used for both
> fresh installs and updates.
> For fresh installs, it could simply import the vcl.sql file.
> For updates, it could query the existing database in order to determine if
> table definitions match vcl.sql and then execute an "alter" statement. This
> will be much easier to code than the current stored procedures in
> update-vcl.sql.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
