Moodle
  1. Moodle
  2. MDL-10805

Question: upgrade.php fails during initial install

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.9
    • Fix Version/s: 1.9
    • Component/s: Questions
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Rank:
      28748

      Description

      Jamie - During a fresh install I received the following:

      Fatal error: Call to undefined function get_records_sql_menu() in /home/aborrow/workspace/moodle/question/upgrade.php on line 120

      Do we need to require /lib/dmllib.php somewhere in order to access the get_records_sql_menu function or should the /lib/db/upgrade.php file be handling that. I'm new to this whole upgrade.php routine and will need to follow it through to get a better handle on it.

      At this point, I cannot install a fresh CVS HEAD. Peace - Anthony

        Activity

        Hide
        Anthony Borrow added a comment -

        Tim - Because this prevents an install, I added you to the watch list in case you wanted to move on this before Jaime gets a chance. Peace - Anthony

        Show
        Anthony Borrow added a comment - Tim - Because this prevents an install, I added you to the watch list in case you wanted to move on this before Jaime gets a chance. Peace - Anthony
        Hide
        Jamie Pratt added a comment -

        this is really strange Anthony! Eloy has reported some errors on upgrade on none MySQL dbs so the upgrade code seems to be running OK. get_records_sql_menu() which is in dmllib is included by setup.php in every moodle script.

        Will take a look at the code to see what the problem might be later today.

        Show
        Jamie Pratt added a comment - this is really strange Anthony! Eloy has reported some errors on upgrade on none MySQL dbs so the upgrade code seems to be running OK. get_records_sql_menu() which is in dmllib is included by setup.php in every moodle script. Will take a look at the code to see what the problem might be later today.
        Hide
        Anthony Borrow added a comment -

        Jamie - It is strange. Just to give you some info about my environment. I installed on my workstation which is running Ubuntu 7.04. I installed from a CVS project created in Eclipse (installed per instructions in docs.moodle.org). I believe it is running PHP 5.2.1 and MySQL 5.0.38. I had a previous installation (prior to the question code) up and running without issue. Let me know if you want me to try on a different environment. Peace - Anthony

        Show
        Anthony Borrow added a comment - Jamie - It is strange. Just to give you some info about my environment. I installed on my workstation which is running Ubuntu 7.04. I installed from a CVS project created in Eclipse (installed per instructions in docs.moodle.org). I believe it is running PHP 5.2.1 and MySQL 5.0.38. I had a previous installation (prior to the question code) up and running without issue. Let me know if you want me to try on a different environment. Peace - Anthony
        Hide
        Jamie Pratt added a comment -

        Seems that the problem was that we were using some dmllib functions in a custom environment check for the question engine. There is a custom check that checks for random questions selecting from a sub category where the sub category's published status is different from the category the random question is in. These questions cause problems and we now have a check for them.

        Obviously on first install we don't need to do this check so I've tested for if this is the installer running with :

        if (!empty($CFG->running_installer) //no test on first installation, no questions to test yet

        and disabled the check in that case. This has fixed this issue.

        Show
        Jamie Pratt added a comment - Seems that the problem was that we were using some dmllib functions in a custom environment check for the question engine. There is a custom check that checks for random questions selecting from a sub category where the sub category's published status is different from the category the random question is in. These questions cause problems and we now have a check for them. Obviously on first install we don't need to do this check so I've tested for if this is the installer running with : if (!empty($CFG->running_installer) //no test on first installation, no questions to test yet and disabled the check in that case. This has fixed this issue.
        Hide
        Jamie Pratt added a comment -

        Thanks for pointing this out Anthony!

        Show
        Jamie Pratt added a comment - Thanks for pointing this out Anthony!
        Hide
        Jamie Pratt added a comment -

        Adding Eloy as QA assignee to take a look at my solution for this problem http://moodle.cvs.sourceforge.net/moodle/moodle/question/upgrade.php?r1=1.7&r2=1.8 Just to see if he has any other suggestion for how this should be handled. Also hope Tim can take a quick look at this and he is already watching this issue. Quick review please.

        Show
        Jamie Pratt added a comment - Adding Eloy as QA assignee to take a look at my solution for this problem http://moodle.cvs.sourceforge.net/moodle/moodle/question/upgrade.php?r1=1.7&r2=1.8 Just to see if he has any other suggestion for how this should be handled. Also hope Tim can take a quick look at this and he is already watching this issue. Quick review please.
        Hide
        Eloy Lafuente (stronk7) added a comment -

        To check for $CFG->running_installer sounds like a good options here (if fact I used it when adding the recent "moodle version" check that must be avoided on install too.

        The only problem I can imagine is how will the environmental stuff react if it receives one null as result. If I'm not wrong, it's possible that, in some loops where results are printed, such null cause some minor problems.

        So, perhaps, it would be a good idea to "clean" the array of results exactly after calculating all them and before any further action. With that, the rest of environment stuff won't receive such nulls that, for now, are uncontrolled.

        How does it sound?

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - To check for $CFG->running_installer sounds like a good options here (if fact I used it when adding the recent "moodle version" check that must be avoided on install too. The only problem I can imagine is how will the environmental stuff react if it receives one null as result. If I'm not wrong, it's possible that, in some loops where results are printed, such null cause some minor problems. So, perhaps, it would be a good idea to "clean" the array of results exactly after calculating all them and before any further action. With that, the rest of environment stuff won't receive such nulls that, for now, are uncontrolled. How does it sound? Ciao
        Hide
        Jamie Pratt added a comment -

        Thanks for your quick response Eloy! Glad you approve of the running_installer test.

        I've seen null returned elsewhere for when the test is not relevant in a custom check that Tim wrote, I think. Hopefully Tim will see this comment and chip in on this.

        Show
        Jamie Pratt added a comment - Thanks for your quick response Eloy! Glad you approve of the running_installer test. I've seen null returned elsewhere for when the test is not relevant in a custom check that Tim wrote, I think. Hopefully Tim will see this comment and chip in on this.
        Hide
        Eloy Lafuente (stronk7) added a comment -

        Ah, I haven't looked to code to see how those nulls are handled in custom checks, perhaps they are being ignored properly now. Cool!

        I commented that because for my no-custom "moodle versions" check I had to keep such null out from $results[], but it's probable that custom checks are supporting that nulls properly, great!

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - Ah, I haven't looked to code to see how those nulls are handled in custom checks, perhaps they are being ignored properly now. Cool! I commented that because for my no-custom "moodle versions" check I had to keep such null out from $results[], but it's probable that custom checks are supporting that nulls properly, great! Ciao
        Hide
        Tim Hunt added a comment -

        Yes, custom checks intentionally allow three outcomes: true, false, and null, for passed, failed, and not-relevant. Jamie's solution looks right to me.

        Show
        Tim Hunt added a comment - Yes, custom checks intentionally allow three outcomes: true, false, and null, for passed, failed, and not-relevant. Jamie's solution looks right to me.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: