[
https://issues.apache.org/jira/browse/VCL-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298779#comment-14298779
]
ASF subversion and git services commented on VCL-764:
-----------------------------------------------------
Commit 1656038 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1656038 ]
VCL-764 - Database changes for VCL 2.4
modified queries that update computer.provisioningid and
statgraphcache.provisioningid: queries were missing constraints that tied
computer/statgraphcache to provisioning table which was causing all records in
computer/statgraphcache to get updated
added DELETE queries in the same section that delete entries from
provisioningOSinstalltype for the same provisioning modules being updated in
that section
> 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)