Upgrade from 5.7.2 -> 5.7.4.1 is broken

[mlabrum]

Hi,

I'm currently in the process of upgrading from concrete 5.7.2 to 5.7.4.1 and having some issues with the migrations running. ( I'm using the upgrade script /index.php/ccm/system/upgrade )

concrete/src/Updater/Migrations/Migrations/Version20141219000000.php -> calls Page::getByPath which generates the following exception

An exception occurred while executing 'SELECT t0.cPath AS cPath1, t0.ppID AS ppID2, t0.cID AS cID3, t0.ppIsCanonical AS ppIsCanonical4, t0.ppGeneratedFromURLSlugs AS ppGeneratedFromURLSlugs5 FROM PagePaths t0 WHERE t0.cID = ? AND t0.ppIsCanonical = ? LIMIT 1' with params ["209", 1]: SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.ppGeneratedFromURLSlugs' in 'field list'

concrete/src/Updater/Migrations/Migrations/Version20150504000000.php -> defines the column ppGeneratedFromURLSlugs but this migration is never ran as the previous migration throws that exception.

I've solved this locally by adding the following code to the first migration ``concrete/src/Updater/Migrations/Migrations/Version20141219000000.php` but that seems a bit hacky.

        $db = \Database::get();
        $pp = $schema->getTable('PagePaths');
        if (!$pp->hasColumn('ppGeneratedFromURLSlugs')) {
            $db->Execute('alter table PagePaths add column ppGeneratedFromURLSlugs tinyint(1) unsigned not null default 0');
            // we have to do this directly because the page path calls below will die otherwise.
        }

[aembler]

Yes, this is a known issue that needs to be documented. You should update from 5.7.2 to 5.7.3 first, then up to 5.7.4.1.

[Remo]

@aembler I always found it quite a hassle to do upgrades like that. I never looked into it, but since every version contains the upgrade scripts for all older versions: Shouldn't it be possible to skip those versions in between? Is it worth looking into this?

[aembler]

I think the issue is that when we attempt to do multiple migrations, we're currently using the most recent code base to do each migration. Going from 5.7.2 to 5.7.4 loads the 5.7.4 code base and runs through 5.7.3 and 5.7.4 migrations. So Version 5.7.3's migration script uses the PagePath's table (likely because it's adding a single page.) Unfortunately, it uses versions 5.7.4's script to do this, and version 5.7.4's single page class references a column that doesn't exist in the Version 5.7.3 migration – but Version 5.7.4 hasn't been migrated yet. I'm not sure if there's an easy way to solve this – thoughts?

[Remo]

Okay I see what you mean. I guess the only approach that would work is if we'd avoid the framework as much as possible or write code that works with two different database structures. The latter would lead to ugly code we could hardly ever remove and avoiding the framework won't always work and isn't nice either but it's what most systems do as far as I've seen.

[joostrijneveld]

What's the recommended approach after upgrading from 5.7.2 to 5.7.4.1 and then running into this issue, other than truncating the database and starting anew?

[aembler]

I would recommend replacing the core with 5.7.3 - upgrading to that - and then going to 5.7.4.2. That should be fine.

Sent from my iPhone

On Jun 13, 2015, at 1:04 PM, Joost Rijneveld notifications@github.com wrote:

What's the recommdend approach after upgrading from 5.7.2 to 5.7.4.1 and then running into this issue, other than truncating the database and starting from anew?

—
Reply to this email directly or view it on GitHub.

[mlabrum]

Pretty much how I've handled this in other projects is to be strict in what
classes migrations can use, for example in this case, migrations should
only be able to use the doctrine sql classes (not ORM) and then your
migrations will pretty much be "standalone".

This does introduce some complexity because you can't reuse functionality
from your entities, but It ensures your migrations always function.

On 14 June 2015 at 08:11, Andrew Embler notifications@github.com wrote:

I would recommend replacing the core with 5.7.3 - upgrading to that - and
then going to 5.7.4.2. That should be fine.

Sent from my iPhone

On Jun 13, 2015, at 1:04 PM, Joost Rijneveld notifications@github.com
wrote:

What's the recommdend approach after upgrading from 5.7.2 to 5.7.4.1 and
then running into this issue, other than truncating the database and
starting from anew?

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#2455 (comment)
.

[joe-meyer]

I've actually wondered if we shouldn't have a property on the migration classes that indicate a minimum core version needed to run the migration. This way, if someone tried to run an update and they were trying to make to big of a jump we could indicate to them which version they needed to use instead of just erroring out.

[aembler]

In the future if you use the Dashboard to update, we inspect every update through concrete5.org, and will tell you if you can go from update A to update B, and even can check out potentially overrides problems

[joostrijneveld]

Nice! Sounds very promising!