28 April 2016, 21:15

Lately we have been seeing a lot of broken pages. The heading comes up but no content and it cannot be edited (wheel thing spins forever). 

After some digging we found that the record for that view was missing in the table view_rows_columns. Inserting a suitable replacement record fixes it. 

There seem to be lots of them.  Has anybody seen anything similar or got any ideas what might be going wrong?

EDIT:

This....

select view.id from view
left join view_rows_columns vrc
on vrc.view = view.id
where vrc.view is null

...returns 23 affected rows, but I have a feeling that it's an ongoing problem. I'm going to fix these and then monitor it to see if we get more. 

29 April 2016, 10:58

Hi Howard,

Yes, I've seen this before with a client I deal with, they use MySql db and were having this exact problem.

I was unable to replicate the problem locally on my machine in mysql or postgres so I haven't worked out the cause of the problem but I believe it results during the copying pages process.

I however applied a workaround fix to the client to avoid the outcome of the problem. so when the lines are missing from view_rows_columns it works out what they should have been from related data and recreates them again.

First I patched the view constructor to check if the data is missing and add it back in

diff --git a/htdocs/lib/view.php b/htdocs/lib/view.php
index 650bab6..e79b678 100644
--- a/htdocs/lib/view.php
+++ b/htdocs/lib/view.php
@@ -311,10 +311,28 @@ class View {
         if (empty($this->columnsperrow)) {
             $this->columnsperrow = get_records_assoc('view_rows_columns', 'view', $this->get('id'), 'row', 'row, columns');
             if (empty($this->columnsperrow)) {
-                // if we are missing this info for some reason we will need to give the page the default layout
-                $default = self::default_columnsperrow();
+                // if we are missing the info for some reason we will give the page it's layout back
+                if ($this->layout) {
+                    if ($rowscols = get_records_sql_array("SELECT vlrc.row, vlc.columns
+                                                           FROM {view_layout_rows_columns} vlrc
+                                                           JOIN {view_layout_columns} vlc ON vlc.id = vlrc.columns
+                                                           WHERE viewlayout = ?", array($this->layout))) {
+                        $default = array();
+                        foreach ($rowscols as $row) {
+                            insert_record('view_rows_columns', (object) array(
+                               'view' => $this->get('id'),
+                               'row' => $row->row, 'columns' => $row->columns));
+                            $default[$row->row] = $row;
+                        }
+                    }
+                }
+                else {
+                    insert_record('view_rows_columns', (object) array(
+                       'view' => $this->get('id'),
+                       'row' => 1, 'columns' => 3));
+                    $default = self::default_columnsperrow();
+                }
                 $this->columnsperrow = $default;
-                insert_record('view_rows_columns', (object) array('view' => $this->get('id'), 'row' => array_values($default)[0]->row, 'columns' => array_values($default)[0]->columns));
             }
         }
     }
 
Then I had to fix up a couple of places that couldn't handle this change - where it was trying to create a new view with id = 0 rather than dealing with an existing one.

diff --git a/htdocs/json/imagebrowser.json.php b/htdocs/json/imagebrowser.json.php
index aac7327..690b7f7 100644
--- a/htdocs/json/imagebrowser.json.php
+++ b/htdocs/json/imagebrowser.json.php
@@ -15,6 +15,8 @@ require(dirname(dirname(__FILE__)) . '/init.php');
 require_once('imagebrowser.php');
 $change                 = param_boolean('change', false);
 $viewid                 = param_integer('id', 0);
+$view                   = param_integer('view', 0);
+$viewid = max($viewid, $view);
 $forumpostid            = param_integer('post', 0);
 $groupid                = param_integer('group', 0);
 $fileid                 = param_alphanum('selected', null);

And

diff --git a/htdocs/lib/imagebrowser.php b/htdocs/lib/imagebrowser.php
index c1aa647..718e222 100644
--- a/htdocs/lib/imagebrowser.php
+++ b/htdocs/lib/imagebrowser.php
@@ -228,10 +228,10 @@ class ImageBrowser {
                         'jssuccesscallback' => 'imageBrowserConfigSuccess',
                         'jserrorcallback'   => 'imageBrowserConfigError',
                         'elements' => $elements,
-                        'viewgroup' => $this->get_view()->get('group'),
+                        'viewgroup' => $this->get('view') ? $this->get_view()->get('group') : null,
                         'group' => $this->get('group'),
-                        'viewinstitution' => $this->get_view()->get('institution'),
-                        'institution' => $this->get_view()->get('institution'),
+                        'viewinstitution' => $this->get('view') ? $this->get_view()->get('institution') : null,
+                        'institution' => $this->get('view') ? $this->get_view()->get('institution') : null,
                         'configdirs' => $configdirs,
                         'plugintype' => 'blocktype',
                         'pluginname' => $this->get('blocktype'),

09 May 2016, 22:17

That's interesting....  thanks for the info :)

21 June 2016, 20:53

I'm assuming these issues are a consequence of transactions being disabled in MySQL (see bug 1514608).  What would have resulted in an deadlock error before those changes now results in pages to get into this state.

We've identified about 20 pages in this state but inserting entries into view_rows_columns has fixed the issue as well. 

I'd been running a similar sql query to be one above on our Mahara instance to identify pages in this state...

SELECT v.id, v.title, u.username, u.firstname, u.lastname
FROM view v
JOIN usr u
ON (v.owner = u.id)
WHERE v.id NOT IN (
  SELECT view
  FROM view_rows_columns
);

Russ

21 June 2016, 21:47

In my defence, I never wanted to run Mahara on MySQL but our server team don't support PostgreSQL. 

Anyway, we've had ongoing, creeping problems with MySQL - schema errors and tricky data corruption like this. It just doesn't work well enough in MySQL :(

23 June 2016, 16:57

Hi Russel,

Hm, you may well be right about that. Without transactions, if the page load crashes while it's partway through setting everything up, that could leave some dangling incomplete data. Or maybe if there were multiple requests going at once, you could wind up with missing records under some circumstances.

The pages you're finding that have this problem, do they date from after the MySQL transaction code was disabled?

Cheers,

Aaron

21 July 2016, 4:13

Hi Aaron,

Apologies for the long delay in replying.  Yes, all the cases we've identified occurred after the MySQL transaction code was disabled.  Looking back at database snapshots before those changes, there are no pages stuck in that state (which is expected due to the transactions).

Russell

10 January 2018, 5:51

For the benefit of those who (like me) were experiencing this problem and landed here, I believe this is fixed here:

https://bugs.launchpad.net/mahara/16.04/+bug/1626805