[
https://issues.apache.org/jira/browse/VCL-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14535293#comment-14535293
]
ASF subversion and git services commented on VCL-870:
-----------------------------------------------------
Commit 1678429 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1678429 ]
VCL-870 - the foreign keys are not in sync between the vcl.sql and
update-vcl.sql files
The idea with these changes is to allow innocuous changes to cascade, but to
restrict changes that could be a problem. Updates to id fields for most tables
are allowed to cascade. It is unlikely that someone would need to change the id
of most entries, but changing them should not be a problem were someone to do
it. However, changes to id fields for resources are not allowed because those
changes cannot be cascaded to resource.subid. In those cases, updates to the
ids are restricted. Additionally, cascading deletes are not allowed for fields
where records should never be deleted. These would include (but not be limited
to) entries in the user, computer, image, managmentnode, and log tables.
Schedules are allowed to be deleted. So schedule deletes can be cascaded.
changes to vcl.sql file:
table structure changes:
-modified affiliation.sitewwwaddress to allow up to 128 chars (was 56)
-added key on continuations.deletefromid
-modified image.prettyname to allow up to 80 chars (was 60)
-modified image.basedoffrevisionid to allow NULL and have the default as NULL
-added key on loginlog.timestamp
-added key on loginlog.authmech
-added key on loginlog.code
-added unique key on managementnode.hostname
-modified sublog.blockRequestid to allow NULL and have the default as NULL
-modified sublog.blockStart to allow NULL and have the default as NULL
-modified sublog.blockEnd to allow NULL and have the default as NULL
-modified user.IMtypeid to allow NULL and have the default as NULL
-modified usergroup.initialmaxtime to be mediumint(8) (was smallint(5))
-modified usergroup.totalmaxtime to be mediumint(8) (was smallint(5))
-modified usergroup.maxextendtime to be mediumint(8) (was smallint(5)) and to
have a default value of 60 (was 30)
-modified vmhost.vmlimit to be smallint(5) (was tinyint(3))
-modified key unique key on vmhost.computer to also include vmprofileid
-added unique key on vmtype.name
-modified xmlrpcLog.xmlrpcKeyid to be mediumint(8) (was smallint(5))
-added key on xmlrpcLog.timestamp
data changes:
-modified basedoffrevisionid value for insert into image table for "No Image"
to be NULL (was 1)
-modified IMtypeid value for inserts into user table to be NULL (was 1)
constraint changes:
-added comments explaining guidelines for when/how ON DELETE and ON UPDATE
should be handled for different fields
-modified blockRequest.groupid
-modified blockRequest.ownerid
-modified blockTimes.blockRequestid
-modified blockWebDate.blockRequestid
-modified blockWebTime.blockRequestid
-modified changelog.logid
-modified changelog.userid
-modified clickThroughs.userid
-modified clickThroughs.imagerevisionid
-modified computer.vmhostid
-modified computer.ownerid
-modified computer.scheduleid
-modified computer.currentimageid
-modified computer.nextimageid
-modified computerloadlog.loadstateid
-moved location of changes for connectlog
-modified connectlog.logid
-modified connectmethodmap.OStypeid
-modified connectmethodmap.OSid
-modified connectmethodmap.imagerevisionid
-added change for continuations.userid
-modified image.ownerid
-added image.basedoffrevisionid
-modified imagerevision.imageid
-modified imagerevisioninfo.imagerevisionid
-modified localauth.userid
-modified log.imageid
-modified log.computerid
-modified managementnode.imagelibgroupid
-modified nathost.resourceid
-moved location of changes for natlog table
-modified natlog.sublogid
-modified nathostcomputermap.computerid
-modified natport.connectmethodportid
-modified natport.reservationid
-modified natport.nathostid
-modified openstackcomputermap.computerid
-modified openstackimagerevision.imagerevisionid
-modified querlog.userid
-modified request.userid
-added request.logid
-modified reservation.computerid
-modified reservation.imageid
-modified reservationaccounts.userid
-modified reservationaccounts.reservationid
-modified resourcemap.resourcegroupid1
-modified resourcemap.resourcegroupid2
-modified resourcemap.resourcetypeid1
-modified resourcemap.resourcetypeid2
-modified scheduletimes.scheduleid
-modified semaphore.managementnodeid
-modified semaphore.computerid
-modified semaphore.imageid
-modified semaphore.imagerevisionid
-modified serverprofile.ownerid
-modified serverprofile.admingroupid
-modified serverprofile.logingroupid
-modified shibauth.userid
-modified statgraphcache.affiliationid
-modified statgraphcache.provisioningid
-modified subimages.imagemetaid
-modified sublog.logid
-modified sublog.imagerevisionid
-modified sublog.predictivemoduleid
-added sublog.blockRequestid
-modified user.affiliationid
-modified user.IMtypeid
-modified usergroup.ownerid
-modified usergroup.affiliationid
-modified usergroupmembers.userid
-modified usergrouppriv.userid
-modified usergrouppriv.userprivtypeid
-modified vmhost.computerid
-modified vmprofile.imageid
> the foreign keys are not in sync between the vcl.sql and update-vcl.sql files
> -----------------------------------------------------------------------------
>
> Key: VCL-870
> URL: https://issues.apache.org/jira/browse/VCL-870
> Project: VCL
> Issue Type: Bug
> Components: database
> Reporter: Josh Thompson
> Fix For: 2.5
>
>
> The foreign keys created by the vcl.sql and update-vcl.sql files are not in
> sync with each other. Some keys are created with things like "ON UPDATE
> CASCADE" in one file and "ON DELETE CASCADE ON UPDATE CASCADE" in the other
> file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
