Moodle
  1. Moodle
  2. MDL-37683

Table installation doesn't occur if reinstalling a Moodle site

    Details

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

      Functionality tests (2.4 and master).

      1. Run unit tests
      2. Browse around your site and make sure that things continue to work exactly as they did before.

      Installation tests (2.4 and master).

      1. Install a fresh site through your browser (without a config.php file)
      2. Create a course.
      3. Delete all your database tables
      4. Browse to the front page and proceed through the installation again.
      5. Delete your database tables, your moodle data and your config file.
      6. Install again but through CLI this time.
      7. In your browser create a course and browse to it.
      8. Delete your database tables.
      9. Run the CLI script to install the database.
      10. Browse your site to make sure things work.

      Upgrade tests.

      1. Install a 2.3 site
      2. Create a few courses, users, and forum posts.
      3. Upgrade it to Moodle 2.4.
      4. Browse around the site and just check things are as they were.
      5. Upgrade it to master.
      6. Browse around again.
      Show
      Functionality tests (2.4 and master). Run unit tests Browse around your site and make sure that things continue to work exactly as they did before. Installation tests (2.4 and master). Install a fresh site through your browser (without a config.php file) Create a course. Delete all your database tables Browse to the front page and proceed through the installation again. Delete your database tables, your moodle data and your config file. Install again but through CLI this time. In your browser create a course and browse to it. Delete your database tables. Run the CLI script to install the database. Browse your site to make sure things work. Upgrade tests. Install a 2.3 site Create a few courses, users, and forum posts. Upgrade it to Moodle 2.4. Browse around the site and just check things are as they were. Upgrade it to master. Browse around again.
    • Affected Branches:
      MOODLE_24_STABLE
    • Fixed Branches:
      MOODLE_24_STABLE
    • Pull 2.4 Branch:
      wip-MDL-37683-m24
    • Pull Master Branch:
      wip-MDL-37683-m25
    • Rank:
      47387

      Description

      If you remove your config.php then visit the site, installation starts. Instead of installing the tables it fails part way through complaining of a missing table.

      I dropped the existing schema, created a new schema with a slightly different name and renamed config.php. when I visit the site in the browser, as there is no config.php, it puts me through the installation process. However after Ive entered the database details instead of creating the tables it gives me the following.

      Table "context" does not exist Debug info:
      Error code: ddltablenotexistStack trace: line 538 of /lib/dml/moodle_database.php: dml_exception thrownline 1332 of /lib/dml/moodle_database.php: call to moodle_database->where_clause()line 5910 of /lib/accesslib.php: call to moodle_database->get_record()line 7170 of /lib/accesslib.php: call to context_system::instance()line 657 of /lib/setup.php: call to get_system_context()line 27 of /config.php: call to require_once()line 50 of /admin/index.php: call to require()

      Deleting the cache directory from moodle data resolved this. Installation now appears to be working correctly.

        Issue Links

          Activity

          Hide
          Andrew Davis added a comment -

          Reinstalling and reusing your old moodle data area is possibly unwise however I feel like, if someone does it, they should not get stuck with a broken site.

          Show
          Andrew Davis added a comment - Reinstalling and reusing your old moodle data area is possibly unwise however I feel like, if someone does it, they should not get stuck with a broken site.
          Hide
          Andrew Davis added a comment -

          This may be resolved by MDL-37545 but Im not sure.

          Show
          Andrew Davis added a comment - This may be resolved by MDL-37545 but Im not sure.
          Hide
          Dan Poltawski added a comment -

          Seeing this with behat. I think that we are using production dataroot with cache early on in the install

          Show
          Dan Poltawski added a comment - Seeing this with behat. I think that we are using production dataroot with cache early on in the install
          Hide
          David Monllaó added a comment -

          Hi,

          Both phpunit and behat bootstrap scripts requires /config.php with the usual CFG->dataroot but stops the lib/setup.php process in the middle, switches CFG->dataroot to CFG->phpunit_dataroot (or CFG->behat_dataroot) and continues with the lib/setup.php processes. Right now CFG->tempdir and CFG->cachedir are set before switching to CFG->phpunit_dataroot and CFG->behat_dataroot.

          Show
          David Monllaó added a comment - Hi, Both phpunit and behat bootstrap scripts requires /config.php with the usual CFG->dataroot but stops the lib/setup.php process in the middle, switches CFG->dataroot to CFG->phpunit_dataroot (or CFG->behat_dataroot) and continues with the lib/setup.php processes. Right now CFG->tempdir and CFG->cachedir are set before switching to CFG->phpunit_dataroot and CFG->behat_dataroot.
          Hide
          Petr Škoda added a comment -

          I am working on a fix...

          Show
          Petr Škoda added a comment - I am working on a fix...
          Hide
          Petr Škoda added a comment - - edited

          I give up.

          1/ The CFG caching is extremely fragile, I am afraid it simply must be turned off at frontapge and all install/upgrade pages.
          2/ ALl MUC caches should be invalidated automatically if we detect mismatch between some system id and and the same id stored in caches. The problem here is if you somehow use different cache data with earlier/older/other database you may actually loose your data (or end up in a state where you need to hack DB to recover)

          Show
          Petr Škoda added a comment - - edited I give up. 1/ The CFG caching is extremely fragile, I am afraid it simply must be turned off at frontapge and all install/upgrade pages. 2/ ALl MUC caches should be invalidated automatically if we detect mismatch between some system id and and the same id stored in caches. The problem here is if you somehow use different cache data with earlier/older/other database you may actually loose your data (or end up in a state where you need to hack DB to recover)
          Hide
          Simon Coggins added a comment -

          I came across this while doing some dev (I had reset the db but not my moodledata). I found a post in the forums where someone was reporting upgrade issues too (https://moodle.org/mod/forum/discuss.php?d=220741).

          Show
          Simon Coggins added a comment - I came across this while doing some dev (I had reset the db but not my moodledata). I found a post in the forums where someone was reporting upgrade issues too ( https://moodle.org/mod/forum/discuss.php?d=220741 ).
          Hide
          Dan Poltawski added a comment -

          Upgraded the priority of this. (It affected almost everyone in the office testing this week)

          Show
          Dan Poltawski added a comment - Upgraded the priority of this. (It affected almost everyone in the office testing this week)
          Hide
          Sam Hemelryk added a comment -

          I'm working on this today, what a twisted issue this is.

          Petr is right in that turning the cache off (or at least disabling the stores) on the front page solve this issue. Presently I'm looking for alternative solutions.

          There is a separate issue for the use of a system ID already. It wasn't included in the design in favour of allowing caches to be sharable, however issues like this have driven the need to change that.
          I've a patch on that issue that will arrive today that will see it become an option of the stores which by default will include an id. For those wanting to share a cache between a cluster or sites will need to configure it after this change.

          Show
          Sam Hemelryk added a comment - I'm working on this today, what a twisted issue this is. Petr is right in that turning the cache off (or at least disabling the stores) on the front page solve this issue. Presently I'm looking for alternative solutions. There is a separate issue for the use of a system ID already. It wasn't included in the design in favour of allowing caches to be sharable, however issues like this have driven the need to change that. I've a patch on that issue that will arrive today that will see it become an option of the stores which by default will include an id. For those wanting to share a cache between a cluster or sites will need to configure it after this change.
          Hide
          Sam Hemelryk added a comment -

          Putting this up for peer-review now.

          Show
          Sam Hemelryk added a comment - Putting this up for peer-review now.
          Hide
          Sam Hemelryk added a comment -

          Just noting that MDL-37500 is also up for peer-review.

          This issue makes it impossible to share caches between sites unless they have the same id.
          MDL-37500 allows the admin to decide what identifier to use (siteid by default) so that if they want to share a cache they can do.

          Show
          Sam Hemelryk added a comment - Just noting that MDL-37500 is also up for peer-review. This issue makes it impossible to share caches between sites unless they have the same id. MDL-37500 allows the admin to decide what identifier to use (siteid by default) so that if they want to share a cache they can do.
          Hide
          Dan Poltawski added a comment -

          Hi Sam,

          This looks fine to me, two questions:

          1. Is cache_helper::update_site_identifier() safe to call in upgrade? (with its cache/locallib inclusion)
          2. Was not really sure why you set the $cacheidentifier default value to '0' rather than an empty string/null or something like that
          Show
          Dan Poltawski added a comment - Hi Sam, This looks fine to me, two questions: Is cache_helper::update_site_identifier() safe to call in upgrade? (with its cache/locallib inclusion) Was not really sure why you set the $cacheidentifier default value to '0' rather than an empty string/null or something like that
          Hide
          Sam Hemelryk added a comment -

          Hi Dan,

          Thanks for looking it over, regarding the two points:

          1. cache/locallib.php is safe to utilise within installation and upgrade scripts. The Cache API was written to be stand alone from Moodle to allow the caching of core structures (dbmeta, config etc) ensure it doesn't use anything within Moodle that is not guaranteed to exist. Also worth mentioning is that it is already utilised within upgrade (although not directly), anyone upgrading from 2.3 will have locallib included as soon as the first DB/config operation happens in order to generate the caches config file.
          2. Yup, the default of 0 was a weird choice. While working on MDL-37500 I refactored slightly the way in which the identifier is collected and held. That used a much more sane method and I've now backported those changes so that we are clear both in that issue and in this issue.

          Putting this up for integration now.

          Many thanks
          Sam

          Show
          Sam Hemelryk added a comment - Hi Dan, Thanks for looking it over, regarding the two points: cache/locallib.php is safe to utilise within installation and upgrade scripts. The Cache API was written to be stand alone from Moodle to allow the caching of core structures (dbmeta, config etc) ensure it doesn't use anything within Moodle that is not guaranteed to exist. Also worth mentioning is that it is already utilised within upgrade (although not directly), anyone upgrading from 2.3 will have locallib included as soon as the first DB/config operation happens in order to generate the caches config file. Yup, the default of 0 was a weird choice. While working on MDL-37500 I refactored slightly the way in which the identifier is collected and held. That used a much more sane method and I've now backported those changes so that we are clear both in that issue and in this issue. Putting this up for integration now. Many thanks Sam
          Hide
          Damyon Wiese added a comment -

          Thanks Sam, this has been pushed to master and 24 branches. I added one commit to remove a ;; and some spelling in comments.

          Show
          Damyon Wiese added a comment - Thanks Sam, this has been pushed to master and 24 branches. I added one commit to remove a ;; and some spelling in comments.
          Hide
          Mark Nelson added a comment -

          Thanks for the clear instructions. Works as expected, passing.

          Show
          Mark Nelson added a comment - Thanks for the clear instructions. Works as expected, passing.
          Hide
          Damyon Wiese added a comment -

          Thanks for your hard work - this issue has made it! Moodle is now a little bit better.

          Regards, Damyon

          Show
          Damyon Wiese added a comment - Thanks for your hard work - this issue has made it! Moodle is now a little bit better. Regards, Damyon

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: