Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-39343

Installing 2.5 over 2.5 previous site breaks badly and other branch switching troubles

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.5
    • Component/s: Caching, Installation
    • Labels:
    • Testing Instructions:
      Hide

      For all DBs, and both using the web installer and the cli installer:

      1. Install a new 2.5 site completely. Verify you end in the frontpage and it works ok.
      2. Using your fav DB admin tool, drop all the tables.
      3. Install 2.5 again (reusing the existing config.php).
      4. TEST: The error in the description of the issue should not happen and the 2nd installation should end without problems (tables, admin and frontpage settings using the web UI / complete when using admin/cli/install_database.php).
      1. Test other normal upgrades and installations.
      2. Test update info fetching
      3. Test add-on installation

      Known problems:

      • MUC causes tons of error logs in theme/image.php during web upgrade
      Show
      For all DBs, and both using the web installer and the cli installer: Install a new 2.5 site completely. Verify you end in the frontpage and it works ok. Using your fav DB admin tool, drop all the tables. Install 2.5 again (reusing the existing config.php). TEST: The error in the description of the issue should not happen and the 2nd installation should end without problems (tables, admin and frontpage settings using the web UI / complete when using admin/cli/install_database.php). Test other normal upgrades and installations. Test update info fetching Test add-on installation Known problems: MUC causes tons of error logs in theme/image.php during web upgrade
    • Affected Branches:
      MOODLE_25_STABLE
    • Fixed Branches:
      MOODLE_25_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      w17_MDL-39343_m25_installupgrade

      Description

      This was detected while re-installing different databases in MDL-38972 testing.

      After a bunch of trial and error iterations, here there are some reliable reproduce instructions:

      1) Install a new 2.5 site. tables, admin user and frontpage settings.

      2) Using your fav DB admin tool, drop all the tables.

      3) Install 2.5 again (reusing the existing config.php). Bot the web interface and the install_database.php CLI lead to the same, next, error:

      Debug info: Table 'moodle_gitintegrationmaster.mdl_glossary_formats' doesn't exist
      SELECT * FROM mdl_glossary_formats WHERE name = ?
      [array (
      0 => 'continuous',
      )]
      Error code: dmlreadexception
      Stack trace:
      line 426 of /lib/dml/moodle_database.php: dml_read_exception thrown
      line 1005 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
      line 1401 of /lib/dml/moodle_database.php: call to mysqli_native_moodle_database->get_records_sql()
      line 1373 of /lib/dml/moodle_database.php: call to moodle_database->get_record_sql()
      line 1352 of /lib/dml/moodle_database.php: call to moodle_database->get_record_select()
      line 919 of /mod/glossary/lib.php: call to moodle_database->get_record()
      line 52 of /mod/glossary/settings.php: call to glossary_get_available_formats()
      line 3380 of /lib/pluginlib.php: call to include()
      line 17 of /admin/settings/plugins.php: call to plugininfo_mod->load_settings()
      line 6379 of /lib/adminlib.php: call to require()
      line 6399 of /lib/adminlib.php: call to admin_get_root()
      line 1487 of /lib/upgradelib.php: call to admin_apply_default_settings()
      line 188 of /admin/index.php: call to install_core()
      

      The same procedure has been used with 2.4 over 2.4 and also with 2.5 over 2.4 and the problem IS NOT reproducible with those combinations. Only 2.5 over 2.5 exhibits it.

      Also, ignore the glossary/settings.php script, it's horrible, old and not good at all (it comes from a pre-subplugins age and nobody has moved it to proper subplugins).

      No matter install_core() calls to cache_factory::disable_stores()... at some point they are accessed (reset happening without notice?) and they have there the information (plugins...) from the previous installation (step 1 above).

      Just adding a simple call to cache_helper::purge_all(); ensures that all the caches are cleaned (as they should be on install) and then the problem stops happening.

      So here it's a simple patch adding that extra cleanup. It should fix this problem and any future one caused by incorrect "reuse" of caches on re-installation.

      In the side of the curiosities, here there are 3:

      C1) The CI servers never have presented this problem. They use a new dataroot on each execution so no cache information is there ever.

      C2) phpunit initialization (or drop & recreation) never have presented this problem. Surely it's because caches are reset on each test execution.

      C3) the muc/config.php file "survives" reinstallation. Not sure if consider that a feature or a bug. In my case it's a feature, as far as I'm using all sort of memcached/doubles/triples combinations and it's nice to have them working all the time, no matter the dev sites are re-installed.

      And this is all. Note that, while the suggested patch solves the problem and I've not been able to break a reinstallation anymore, I'm not sure if it's the real problem or the problem is the call to disable_stores() not really disabling them (session ones being the problematic perhaps?).

      In the other side, it does not hurt to have that explicit purge_all() to ensure all the configured caches are really empty at that stage.

      So, for your entire considerations!

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              skodak Petr Skoda
              Reporter:
              stronk7 Eloy Lafuente (stronk7)
              Integrator:
              Dan Poltawski Dan Poltawski
              Tester:
              Mark Nelson Mark Nelson
              Participants:
              Component watchers:
              Matteo Scaramuccia, Amaia Anabitarte, Carlos Escobedo, Ferran Recio, Ilya Tregubov, Sara Arjona (@sarjona), Matteo Scaramuccia, Andrew Lyons, Dongsheng Cai, Huong Nguyen, Jun Pataleta, Michael Hawkins, Shamim Rezaie, Simey Lameze
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Fix Release Date:
                14/May/13