Upgrade to 3.1.1-2 from 2.4.8 PHP Fatal error: Call to a member function getStatus()

lines like error_log(print_r($newRevision, true)); should work. Just replace the variable with the actual name.

I would add error_log(print_r($updatedFile->getFileId(), true)); before this line pkp-lib/PKPSubmissionFileDAO.inc.php at ojs-stable-3_1_1 · pkp/pkp-lib · GitHub to find out the fileId where the problem is.

But also here ojs/Upgrade.inc.php at ojs-stable-3_1_1 · pkp/ojs · GitHub I would add error_log("SubmissionId"); error_log(print_r($submission->getId(), true)); Because if the $updatedFile->getFileId() returns another null, you can at least check what the submission id is where the problem occurs and start tracking it there.

Thank you. I’m starting a new round of upgrade with the relevant debug code and also using 3.1.1-4 which as been just released. Will report back in the morning.

@ajnyga

Ok, this is what I got:

(mysql): SELECT * FROM user_settings WHERE user_id = '23'

-----<hr>
31350
31350
0
PHP Warning:  assert(): Assertion failed in /var/www/ojs/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 352
PHP Fatal error:  Call to a member function getFilePath() on null in /var/www/ojs/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 374
-----<hr>

Since I have added the below debug:

  // Make sure that the implementation of the updated file                                                                      │·······························································································································
                // is compatible with its genre.                                                                                              │·······························································································································
                error_log(print_r($updatedFile->getFileId(), true));                                                                          │·······························································································································
                $updatedFile = $this->_castToGenre($updatedFile);                                                                             │·······························································································································
                                                                                                                                              │·······························································································································
                // Complete the identifying data of the previous file if not given.                                                           │·······························································································································
                $previousFileId = (int)($previousFileId ? $previousFileId : $updatedFile->getFileId());                                       │·······························································································································
                $previousRevision = (int)($previousRevision ? $previousRevision : $updatedFile->getRevision());                               │·······························································································································
                                                                                                                                              │·······························································································································
                // Retrieve the previous file.                                                                                                │·······························································································································
                error_log(print_r($previousFileId, true));                                                                                    │·······························································································································
                error_log(print_r($previousRevision, true));                                                                                  │·······························································································································
                $previousFile = $this->getRevision($previousFileId, $previousRevision);                                                       │·······························································································································
                assert(is_a($previousFile, 'SubmissionFile'));                        

The codes should the getFileID and somehow the previousFileID and the previousRevision
31350
31350
0

In this case:

mysql> select * from article_files where file_id = 31350;
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
| file_id | revision | source_file_id | source_revision | article_id | file_name              | file_type       | file_size | original_file_name     | file_stage | viewable | date_uploaded       | date_modified       | round | assoc_id |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
|   31350 |        0 |           NULL |            NULL |      31350 | 31350-35163-10-PB.html | application/pdf |    324352 | 31350-35163-10-PB.html |          7 |     NULL | 2010-03-06 04:28:12 | 2010-03-06 04:28:12 |     1 |     NULL |
|   31350 |        1 |          31349 |            NULL |      30338 | 30338-31350-1-RV.pdf   | application/pdf |     18501 | 30338-31349-1-SM.pdf   |          2 |     NULL | 2009-04-06 15:36:20 | 2009-04-06 15:36:20 |     1 |     NULL |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
2 rows in set (0.01 sec)

I’m not sure about those results, but is this because file_id is not unique? Also, file_id has same article_id on the first, but not on the second(also file name is weird)?

Also, here are all non unique file_id - Not sure if this is a problem

mysql> select file_id, COUNT(*) from article_files GROUP BY file_id HAVING count(*) > 1;
+---------+----------+
| file_id | COUNT(*) |
+---------+----------+
|   31350 |        2 |
|   31898 |        2 |
|   31904 |        2 |
|   32051 |        3 |
|   32572 |        2 |
|   32573 |        4 |
|   37000 |        2 |
|   37265 |        2 |
|   37457 |        2 |
|   37458 |        3 |
|   39933 |        2 |
|   42195 |        2 |
|   44576 |        2 |
|   44854 |        4 |
|   44867 |        3 |
|   44868 |        3 |
|   44871 |        3 |
|   44890 |        3 |
|   44895 |        3 |
|   44897 |        3 |
|   44899 |        3 |
|   44901 |        3 |
|   44909 |        3 |
|   44919 |        3 |
|   44929 |        2 |
|   44977 |        3 |
|   44978 |        2 |
|   44979 |        2 |
|   44980 |        2 |
|   44981 |        2 |
|   44982 |        2 |
|   44991 |        2 |
|   45075 |        4 |
|   45079 |        3 |
|   45087 |        3 |
|   45119 |        3 |
|   45131 |        2 |
|   45143 |        2 |
|   45145 |        2 |
|   45155 |        2 |
|   45163 |        2 |
|   45166 |        2 |
|   45169 |        2 |
|   45175 |        3 |
|   45179 |        3 |
|   45183 |        3 |
|   45194 |        2 |
|   45256 |        2 |
|   45258 |        2 |
|   45259 |        2 |
|   45263 |        2 |
|   45282 |        3 |
|   45294 |        2 |
|   45298 |        2 |
|   45301 |        2 |
|   45358 |        2 |
|   45359 |        2 |
|   45365 |        2 |
|   45388 |        2 |
|   45389 |        2 |
|   45403 |        2 |
|   45413 |        2 |
|   45415 |        2 |
|   45436 |        2 |
|   45578 |        3 |
|   45611 |        2 |
|   45624 |        2 |
|   45625 |        2 |
|   45645 |        2 |
|   45650 |        2 |
|   45677 |        3 |
|   45678 |        2 |
|   45685 |        2 |
|   45796 |        2 |
|   45801 |        2 |
|   45857 |        2 |
|   45867 |        2 |
|   45869 |        2 |
|   45871 |        2 |
|   45875 |        2 |
|   45913 |        2 |
|   45919 |        2 |
|   45955 |        2 |
|   45956 |        2 |
|   45959 |        2 |
|   45998 |        2 |
|   46000 |        2 |
|   46006 |        2 |
|   46016 |        3 |
|   46027 |        2 |
|   46028 |        3 |
|   46034 |        2 |
|   46138 |        2 |
|   46144 |        2 |
|   46155 |        2 |
|   46182 |        6 |
|   46199 |        2 |
|   46248 |        4 |
|   46252 |        2 |
|   46253 |        2 |
|   46335 |        2 |
+---------+----------+

And I have some pretty high numbers in the file_id column as well…

|  46437 |        1 |
|  313500000 |        1 |
|  341230000 |        1 |
|  342900000 |        1 |
| 3135031354 |        1 |
| 3135031358 |        1 |
| 3135031359 |        1 |
| 3135031360 |        1 |
| 3135031361 |        1 |
| 3135031362 |        1 |
| 3135031363 |        1 |
+------------+----------+

Last edit:
Also: see how 3150 is the smallest non-duplicated file_id ? This probably means something right? Too unusal that it would error out exactly on the smallest numeber (if it goes sequencially)

I do not think that any file should have revision 0? It should be at least 1. That is the source of the error I bet.

In the original database, do you have a lot of files with revision number 0?

The file_id also looks weird. Is that in the original database?

edit: the file_id number 31350 has problems and the weird file_id’s start with 31350. That can not be a coincidence?

edit2: 3135031363 has actually two file_id’s together for some reason. Maybe the cause of your long loop we discussed above. I looks like two file_id’s have been embedded together somehow…

ok so you do not actually have two file_id’s with 31350.

On row 1 31350 is actually the article/submission id. The real file_id there is 35163 as you can see from the original file_name

On row 2 the file_id is the actual file_id and the submission/article id is 30338.

Look at the original database. Search for submissions 31350 and 30338 and see what files are attached to those two submissions/articles. There has to be something weird there.

In the original database, what kind of revisions do you have for file_id 35163? Do you have a zero there? The one mentioned above should be revision 10 as you can see from the filename.

Yes, this is from the original database.

mysql> select file_id from article_files where revision = 0;
+---------+
| file_id |
+---------+
|   31350 |
+---------+
1 row in set (0.02 sec)

That’s the only one with revision 0:

Edit: here is for 35163

mysql> select * from article_files where file_id = 35163;
+---------+----------+----------------+-----------------+------------+----------------------+-----------------+-----------+-------------------------------------+------------+----------+---------------------+---------------------+-------+----------+
| file_id | revision | source_file_id | source_revision | article_id | file_name            | file_type       | file_size | original_file_name                  | file_stage | viewable | date_uploaded       | date_modified       | round | assoc_id |
+---------+----------+----------------+-----------------+------------+----------------------+-----------------+-----------+-------------------------------------+------------+----------+---------------------+---------------------+-------+----------+
|   35163 |        1 |           NULL |            NULL |      31350 | 31350-35163-1-PB.pdf | application/pdf |    143981 | Microsoft Word - artigo busques.pdf |          7 |     NULL | 2009-06-15 15:50:31 | 2009-06-15 15:50:31 |     1 |     NULL |
+---------+----------+----------------+-----------------+------------+----------------------+-----------------+-----------+-------------------------------------+------------+----------+---------------------+---------------------+-------+----------+
1 row in set (0.00 sec)

can you show the whole row with *

mysql> select *  from article_files where revision = 0;
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
| file_id | revision | source_file_id | source_revision | article_id | file_name              | file_type       | file_size | original_file_name     | file_stage | viewable | date_uploaded       | date_modified       | round | assoc_id |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
|   31350 |        0 |           NULL |            NULL |      31350 | 31350-35163-10-PB.html | application/pdf |    324352 | 31350-35163-10-PB.html |          7 |     NULL | 2010-03-06 04:28:12 | 2010-03-06 04:28:12 |     1 |     NULL |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
1 row in set (0.02 sec)

Btw: Have I said how awesome you are to be checking this with me? You are awesome :dark_sunglasses:

I bet the system is crashing because of that 0. It should be 10. (31350-35163-10-PB.html)

Does that same file_id 31350 have other revisions?

Nope, only 0 and 1.

I’m changing that to 10 to see what will happen.

EDIT:

You think those big numbers will cause issues as well?

If you do not have them in the original database, it could be that something in the upgrade creates them. Could be this the 0 revision issue or could be something else I guess.

But maybe @asmecher would have time to comment whether a revision can be 0 in OJS2? Because there are no other rows with the same file_id in the database, I would use revision 1 there.

Another question, does file 35163 have several revisions in the original database? (sorry you already answered that…)

I have a new theory. The row with the revision 0 should actually be:

+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
| file_id | revision | source_file_id | source_revision | article_id | file_name              | file_type       | file_size | original_file_name     | file_stage | viewable | date_uploaded       | date_modified       | round | assoc_id |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
|   35163 |        10 |           NULL |            NULL |      31350 | 31350-35163-10-PB.html | application/pdf |    324352 | 31350-35163-10-PB.html |          7 |     NULL | 2010-03-06 04:28:12 | 2010-03-06 04:28:12 |     1 |     NULL |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+

Because the original filename is 31350-35163-10-PB.html that is article_id-file_id-revision-

No, 35163 only have revision 1.

Wait: Should I change the revision on the file_id 35163? Because this seems correct to me:

mysql> mysql> select * from article_files where file_id = 35163;
+---------+----------+----------------+-----------------+------------+----------------------+-----------------+-----------+-------------------------------------+------------+----------+---------------------+---------------------+-------+----------+
| file_id | revision | source_file_id | source_revision | article_id | file_name            | file_type       | file_size | original_file_name                  | file_stage | viewable | date_uploaded       | date_modified       | round | assoc_id |
+---------+----------+----------------+-----------------+------------+----------------------+-----------------+-----------+-------------------------------------+------------+----------+---------------------+---------------------+-------+----------+
|   35163 |        1 |           NULL |            NULL |      31350 | 31350-35163-1-PB.pdf | application/pdf |    143981 | Microsoft Word - artigo busques.pdf |          7 |     NULL | 2009-06-15 15:50:31 | 2009-06-15 15:50:31 |     1 |     NULL |
+---------+----------+----------------+-----------------+------------+----------------------+-----------------+-----------+-------------------------------------+------------+----------+---------------------+---------------------+-------+----------+
1 row in set (0.00 sec)

Or was that a typo and you meant the 31350 ?

mysql> select *  from article_files where revision = 0;
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
| file_id | revision | source_file_id | source_revision | article_id | file_name              | file_type       | file_size | original_file_name     | file_stage | viewable | date_uploaded       | date_modified       | round | assoc_id |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
|   31350 |        0 |           NULL |            NULL |      31350 | 31350-35163-10-PB.html | application/pdf |    324352 | 31350-35163-10-PB.html |          7 |     NULL | 2010-03-06 04:28:12 | 2010-03-06 04:28:12 |     1 |     NULL |
+---------+----------+----------------+-----------------+------------+------------------------+-----------------+-----------+------------------------+------------+----------+---------------------+---------------------+-------+----------+
1 row in set (0.02 sec)

This row has even more weird things in it. The filename says html and the filetype says pdf.

If it is not an important file, it could be a good idea to try removing the whole line before the upgrade. It is clearly corrupted in some way that is hard to say anymore.

I am talking about changes made to the row with the revision 0 in it.

Notice how the file_id and the article_id are the same (31350) but in the file name you can see that they should not be the same. The file_id should be 35163. Or at least it looks like it.

I’m suspecting something broke the DB some time ago: There are too many issues with it. But nothing much I can do right now I think, only try to somehow get into a good shape. I don’t mind excluding a few entries if that is what is required.

do you have the big file_id numbers in the original database?

If not, I would try removing the row with revision 0 and try the upgrade again.

Yep, there are there in the original. All this info above is from the original.

wow, that looks bad then. At some point something went very wrong with file_id 31350 and it has done a lot of damage it seems.

Try removing the line and run the upgrade again.

After that I have a very interesting suggestion. What if you download this plugin for OJS2 GitHub - lepidus/fullJournalTransfer: OJS plugin for importing/exporting a journal with all its private information (e.g. submitted articles, reviews, editorial decisions, etc.) > transfer your whole OJS installation using that plugin to a brand new and empty OJS2 installation and see if that fixes the issues with the file_id’s. Of course it could be that your database will not work with the plugin…

Excellent suggestion. I was thinking of something on those lines sometime ago but completly forgot it. I did not knew that plugin existed. I will give it a try tomorrow.

Today I will try another round of upgrade without the 31350 and revision 0