[ 
https://issues.apache.org/jira/browse/VCL-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301630#comment-14301630
 ] 

ASF subversion and git services commented on VCL-764:
-----------------------------------------------------

Commit 1656536 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1656536 ]

VCL-764 - Database changes for VCL 2.4

Versions of vcl.sql before the 2.3 release had a unique key on 
userpriv.(userid, usergroupid, privnodeid, userprivtypeid) which, due to some 
fields being allowed to be NULL, didn't prevent duplicates. The vcl.sql file 
released as part of 2.3 fixed this by removing that unique key and adding 
separate ones on userpriv.(userid, privnodeid, userprivtypeid) and 
userpriv.(usergroupid, privnodeid, userprivtypeid). However, this never made 
its way into the update-vcl.sql file. This commit brings userpriv to the proper 
table structure.

update-vcl.sql:
-modified Add3ColUniqueIndexIfNotExist: added deleteduplicates argument - 
passing 1 for it will cause any existing duplicates in the table to be dropped 
by calling 'ALTER IGNORE TABLE' instead of 'ALTER TABLE'
-modified one existing call to Add3ColUniqueIndexIfNotExist to include extra 
argument
-added section to modify keys on userpriv table
  -drop existing constraints on userpriv.userid
  -drop existing indices on userpriv.userid
  -add 3 column unique index on userpriv.(userid, privnodeid, userprivtypeid)
  -add 3 column unique index on userpriv.(usergroupid, privnodeid, 
userprivtypeid)
  -add constraint on userpriv.userid to user.id with cascade on both delete and 
update

> 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)

Reply via email to