Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-12194

Unknown column 'field_show_novalue' in 'field list' [1054]

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.1.0-dev
    • Fix Version/s: 3.1.0-b1
    • Component/s: None
    • Labels:
      None

      Description

      From area51:

      General Error
      SQL ERROR [ mysqli ]
       
      Unknown column 'field_show_novalue' in 'field list' [1054]
       
      SQL
       
      INSERT INTO phpbb_profile_fields (field_name, field_type, field_ident, field_length, field_minlen, field_maxlen, field_novalue, field_default_value, field_validation, field_required, field_show_novalue, field_show_on_reg, field_show_on_pm, field_show_on_vt, field_show_profile, field_hide, field_no_view, field_active, field_order) VALUES ('phpbb_interests', 'profilefields.type.text', 'phpbb_interests', '3|30', '2', '500', '', '', '.*', 0, 0, 0, 0, 0, 1, 0, 0, 1, 3)
       
      BACKTRACE
       
      FILE: (not given by php)
      LINE: (not given by php)
      CALL: msg_handler()
       
      FILE: [ROOT]/phpbb/db/driver/driver.php
      LINE: 803
      CALL: trigger_error()
       
      FILE: [ROOT]/phpbb/db/driver/mysqli.php
      LINE: 181
      CALL: phpbb\db\driver\driver->sql_error()
       
      FILE: [ROOT]/phpbb/db/migration/profilefield_base_migration.php
      LINE: 70
      CALL: phpbb\db\driver\mysqli->sql_query()
       
      FILE: (not given by php)
      LINE: (not given by php)
      CALL: phpbb\db\migration\profilefield_base_migration->create_custom_field()
       
      FILE: [ROOT]/phpbb/db/migrator.php
      LINE: 455
      CALL: call_user_func_array()
       
      FILE: [ROOT]/phpbb/db/migrator.php
      LINE: 401
      CALL: phpbb\db\migrator->run_step()
       
      FILE: [ROOT]/phpbb/db/migrator.php
      LINE: 250
      CALL: phpbb\db\migrator->process_data_step()
       
      FILE: [ROOT]/phpbb/db/migrator.php
      LINE: 202
      CALL: phpbb\db\migrator->try_apply()
       
      FILE: [ROOT]/phpbb/db/migrator.php
      LINE: 153
      CALL: phpbb\db\migrator->try_apply()
       
      FILE: [ROOT]/install/database_update.php
      LINE: 222
      CALL: phpbb\db\migrator->update()
      

        Activity

        Hide
        EXreaction EXreaction [X] (Inactive) added a comment - - edited

        I know what happened here.

        This should have been added in 3.0.11-RC2.
        310/extensions requires 30x/3.0.11, which requires the RC2 migration

        a51 had a version # of 3.1.0-dev. Around the time of migrations, 3.0.11 was out, but a51 hadn't run the old database update since before 3.0.11-rc2. When we switched to migrations, some migrations were missed because the 3.0.x migrations only checked for <= 3.0.x version number.

        Although this could never happen again this way, new 3.0.x migrations shouldn't check just the version number if db changes are made. The reason however is because going from say 3.0.12 to 3.1.0, if 3.0.13 added a new column, we wouldn't know that the 3.0.13 migration would be run before the 3.1 migrations (without changing the 3.1.0-dev migration to depend on the newer 3.0.x migrations, which we don't want to do).

        For this reason, I'm marking this as not a bug as it's impossible to reproduce without doing so purposefully (checking out a really old version of develop when migrations were first added and then updating).

        You'll have to just add this column manually for a51.

        Show
        EXreaction EXreaction [X] (Inactive) added a comment - - edited I know what happened here. This should have been added in 3.0.11-RC2. 310/extensions requires 30x/3.0.11, which requires the RC2 migration a51 had a version # of 3.1.0-dev. Around the time of migrations, 3.0.11 was out, but a51 hadn't run the old database update since before 3.0.11-rc2. When we switched to migrations, some migrations were missed because the 3.0.x migrations only checked for <= 3.0.x version number. Although this could never happen again this way, new 3.0.x migrations shouldn't check just the version number if db changes are made. The reason however is because going from say 3.0.12 to 3.1.0, if 3.0.13 added a new column, we wouldn't know that the 3.0.13 migration would be run before the 3.1 migrations (without changing the 3.1.0-dev migration to depend on the newer 3.0.x migrations, which we don't want to do). For this reason, I'm marking this as not a bug as it's impossible to reproduce without doing so purposefully (checking out a really old version of develop when migrations were first added and then updating). You'll have to just add this column manually for a51.
        Hide
        bantu Andreas Fischer added a comment -

        I'm not sure this is how migrations are supposed to work. It was my impression that migrations have been designed in a way to properly allow non-linear development of phpBB.

        Show
        bantu Andreas Fischer added a comment - I'm not sure this is how migrations are supposed to work. It was my impression that migrations have been designed in a way to properly allow non-linear development of phpBB.
        Hide
        EXreaction EXreaction [X] (Inactive) added a comment -

        They do allow non-linear development. This issue only arose because the effectively installed should have been written differently for that migration to account for people running 3.1.0-dev but who have not run the db update in a while. It's no longer an issue because nobody is going to be running 3.1 dev code from years ago and then try to update it just now.

        After 3.0 is no longer updated we will have no issues and will never again need to use effectively_installed.

        Show
        EXreaction EXreaction [X] (Inactive) added a comment - They do allow non-linear development. This issue only arose because the effectively installed should have been written differently for that migration to account for people running 3.1.0-dev but who have not run the db update in a while. It's no longer an issue because nobody is going to be running 3.1 dev code from years ago and then try to update it just now. After 3.0 is no longer updated we will have no issues and will never again need to use effectively_installed.
        Hide
        naderman Nils Adermann added a comment -

        Just ran into this on Area51.

        Show
        naderman Nils Adermann added a comment - Just ran into this on Area51.
        Hide
        EXreaction EXreaction [X] (Inactive) added a comment -

        This is not a phpBB bug, this must be fixed manually for area51.

        Show
        EXreaction EXreaction [X] (Inactive) added a comment - This is not a phpBB bug, this must be fixed manually for area51.
        Hide
        nickvergessen Joas Schilling added a comment -

        With effectively_installed() it is quite easy to just add a new migration to add this column, if it is missing.
        I added a PR for it.

        Show
        nickvergessen Joas Schilling added a comment - With effectively_installed() it is quite easy to just add a new migration to add this column, if it is missing. I added a PR for it.
        Hide
        bantu Andreas Fischer added a comment -

        Apparently merged by naderman.

        Show
        bantu Andreas Fischer added a comment - Apparently merged by naderman.
        Hide
        bantu Andreas Fischer added a comment -

        Still getting this on area51. Reopening.

        Show
        bantu Andreas Fischer added a comment - Still getting this on area51. Reopening.
        Hide
        nickvergessen Joas Schilling added a comment -

        Fixed, after I deleted the broken migration from the database and rerun database_update.php

        Show
        nickvergessen Joas Schilling added a comment - Fixed, after I deleted the broken migration from the database and rerun database_update.php

          People

          • Assignee:
            nickvergessen Joas Schilling
            Reporter:
            bantu Andreas Fischer
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development