upgrade-sql fails

44 views
Skip to first unread message

xentr...@gmail.com

unread,
Mar 12, 2017, 1:03:10 PM3/12/17
to AtoM Users
I upgraded my atom 2.2.1 to 2.3.1 on an Ubuntu 14.04 VPS with apache, php7.1 and mysql 5.6, following the instructions from https://www.accesstomemory.org/en/docs/2.3/admin-manual/installation/upgrading/
When I reached https://www.accesstomemory.org/en/docs/2.3/admin-manual/installation/upgrading/#run-the-upgrade-task I faced an error when running php symfony tools:upgrade-sql

There are several calls to function modify($query, $parameters) of /lib/QubitPdo.class.php, using only 1 argument ($query) and omitting the second argument. This causes a php error that stops the upgrade-sql tool execution.

I managed to run it by making the second argument of the function optional ie function modify($query, $parameters='')

The tool execution concluded without any errors and it looks like it added a few records in the databse, without modifying its structure but I cannot be sure that everything worked as intended.

Although I searched the forum for this problem, I couldn't find anything related.
Please let me know if my fix was correct.





mi...@artefactual.com

unread,
Mar 13, 2017, 6:59:44 PM3/13/17
to AtoM Users, xentr...@gmail.com
Hi,

What version of ElasticSearch are you running on that server?

Cheers,
Mike Cantelon
Artefactual Systems

Mike G

unread,
Mar 13, 2017, 7:04:43 PM3/13/17
to AtoM Users, xentr...@gmail.com
Hello,

That's a good catch, I'm pretty surprised it hasn't come up before in our testing or with other users. I think the more correct fix would be making $parameters = array(), as that's the type we usually use for that sort of thing. As far as if your database structure is fine, I'm not sure we have any sure-fire way to tell it's working other than just using the application itself and checking for errors. My suspicion is you're OK though--the $parameters array we usually just check with isset($parameters['particular-option']), so making it just '' would still be legal.

Thanks for the report and I'll file a bug ticket to rectify this.


On Sunday, March 12, 2017 at 10:03:10 AM UTC-7, xentr...@gmail.com wrote:

xentr...@gmail.com

unread,
Mar 13, 2017, 7:10:02 PM3/13/17
to AtoM Users, xentr...@gmail.com
I am running version 1.7.6 (although that seems to me as irrelevant to my issue...)

xentr...@gmail.com

unread,
Mar 13, 2017, 7:16:02 PM3/13/17
to AtoM Users, xentr...@gmail.com
Thanks!
It looks like everything works well, so I am just crossing my fingers.
At some point I suspected it had something to do with my php version (7.1), being more strict than php5.6, which I used for the previous upgrade from 1.3 to 2.2.1.
I compared /lib/QubitPdo.class.php from versions 2.2.1, 2.3.0 and 2.3.1 and they are all the same.

Now that I pointed out the problem, can anyone else confirm it? Otherwise I should examine my setup.
Would it help to post my phpinfo() output or a part of it?

Mike G

unread,
Mar 13, 2017, 7:17:26 PM3/13/17
to AtoM Users, xentr...@gmail.com
Hi,

I filed a ticket here https://projects.artefactual.com/issues/10971 and we'll fix this soon. Also I was mistaken in my previous reply about us using $parameters with isset, it's instead used to pass arguments into the SQL query (my bad). I'm actually not sure what the side effect would be with passing '' instead of array() in this case.

Mike G

unread,
Mar 13, 2017, 7:18:52 PM3/13/17
to AtoM Users, xentr...@gmail.com
Hi,

It's definitely a legitimate code issue you've found imo. I think you've hit the nail on the head that it's just a PHP versioning or setup issue on whether or not the error gets reported or hidden. I've unfortunately encountered a lot of situations like this with PHP in the past.

mi...@artefactual.com

unread,
Mar 13, 2017, 7:29:54 PM3/13/17
to AtoM Users, xentr...@gmail.com
Ah true, sorry, I replied in wrong thread.

Mike

xentr...@gmail.com

unread,
Mar 13, 2017, 7:30:03 PM3/13/17
to AtoM Users, xentr...@gmail.com
Of course it is a legitimate issue and you describe it very clearly in the ticket. Maybe my discovery has to do with my error reporting level (22527).

My php parameters containing "error" are:
  • display_errors Off
  • display_startup_errors Off
  • error_append_string no value
  • error_log no value
  • error_prepend_string no value
  • error_reporting 22527
  • html_errors On
  • ignore_repeated_errors Off
  • log_errors On
  • log_errors_max_len 1024
  • track_errors Off
  • xmlrpc_error_number 0
  • xmlrpc_errors Off
I want to try and run it with your solution (array()).
Would taking a db backup be adequate, in case anything gets messed up?
I will then make a db comparison and post the results here.

xentr...@gmail.com

unread,
Mar 13, 2017, 7:55:54 PM3/13/17
to AtoM Users, xentr...@gmail.com
Okay, I ran it again, using 
public static function modify($query, $parameters=array())

It ran without a problem:
>> upgrade-sql Successfully upgraded to Release 2.3.1 v138

There was no change in the database whatsoever, so we can safely assume that my first attempt worked as well. :-)))

Thank you Mike for all your help and attention!

xentr...@gmail.com

unread,
Mar 13, 2017, 7:59:53 PM3/13/17
to AtoM Users, xentr...@gmail.com
...but the fact that noone ever reported this, after all these versions, is still bugging me (pun intented. Actually, I wrote this for the pun... :-)

Mike G

unread,
Mar 20, 2017, 2:48:05 PM3/20/17
to AtoM Users, xentr...@gmail.com
hehe, well, I think PHP has its own mind on which coding mistakes are "notices" or "warnings" or "errors" and it depends on which version you're running and other factors. We've even had developers who see certain errors given their setup vs. others, so it's definitely a possibility. I'll likely be fixing this to =array() today.

take care.
Reply all
Reply to author
Forward
0 new messages