Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[stable10] Migration for bigint on DAV tables #33603

Merged
merged 2 commits into from
Nov 22, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 65 additions & 0 deletions apps/dav/appinfo/Migrations/Version20181115210344.php
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
<?php
/**
* @author Vincent Petry <pvince81@owncloud.com>
*
* @copyright Copyright (c) 2018, ownCloud GmbH
* @license AGPL-3.0
*
* This code is free software: you can redistribute it and/or modify
* it under the terms of the GNU Affero General Public License, version 3,
* as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU Affero General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public License, version 3,
* along with this program. If not, see <http://www.gnu.org/licenses/>
*
*/

namespace OCA\DAV\Migrations;

use Doctrine\DBAL\Schema\Schema;
use Doctrine\DBAL\Types\Type;
use OCP\Migration\ISchemaMigration;

/*
* Convert id columns of many DAV-related tables to bigint.
*
* Note that some of these migrations might have existed before
* but some update paths did not trigger them properly, so this
* migration here exists to align all update paths.
*/
class Version20181115210344 implements ISchemaMigration {

/**
* @param Schema $schema
* @param array $options
*/
public function changeSchema(Schema $schema, array $options) {
$tableNames = [
'addressbookchanges',
'addressbooks',
'calendarchanges',
'calendarobjects',
'calendars',
'calendarsubscriptions',
'cards',
'cards_properties',
'dav_shares',
'schedulingobjects',
];
$prefix = $options['tablePrefix'];

foreach ($tableNames as $tableName) {
$table = $schema->getTable("{$prefix}{$tableName}");
$idColumn = $table->getColumn('id');
if ($idColumn->getType()->getName() !== Type::BIGINT) {
$idColumn->setType(Type::getType(Type::BIGINT));
$idColumn->setOptions(['length' => 20]);
}
}
}
}
2 changes: 1 addition & 1 deletion version.php
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@
// We only can count up. The 4. digit is only for the internal patchlevel to trigger DB upgrades
// between betas, final and RCs. This is _not_ the public version number. Reset minor/patchlevel
// when updating major/minor version number.
$OC_Version = [10, 0, 10, 4];
$OC_Version = [10, 0, 10, 5];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hum - shouldn't that version increase be either 10,0,11 ?

Otherwise this seems strange

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. We increment the Patch Level in release. The 4th version is used for Database update

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is mostly for people who have an existing stable10 instance and do a git pull... we can discuss separately whether we want to continue this practice or go with "don't use git in production"


// The human readable string
$OC_VersionString = '10.0.10';
Expand Down