I’ve been messing with this for 5 hours now and I’m at a loss. I can only assume the issue boils down to some strange permissions with the Cloud9 file system or something.
I spun up a PHP workspace, which comes by default with PHP 5.5 and MySQL 5.5 installed.
Next, I upgraded PHP to version 7.0 with the expectation of running my Laravel code base (which requires PHP 7.0)
I then copied in my source code and tried running my database migrations. I go the following error:
SQLSTATE: Syntax error or access violation: 1140 Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause
Here’s the weird bit… This code ran just fine on another server, so I know there’s nothing wrong with the queries being generated by Laravel. So I took a look at the query in question. Tracing the error to the exact
execute() statement that initiated it, here was the query being run:
select count(*) as aggregate from `images` where `images`.`imageable_id` = 1 and `images`.`imageable_id` is not null and `images`.`imageable_type` = "App\\Models\\Property" and `generated` = 0 order by `order` asc
order by statement on a query which obviously returns a single row is a bit out of place, but that’s just how Laravel created the query. More importantly, I tried copying and pasting this exact query into the MySQL REPL and it ran without an issue! No errors, and it returned a value exactly as expected.
So PDO is throwing an error, but MySQL isn’t… yet PDO claims the error is straight from MySQL.
Now here’s where it gets really weird… I thought maybe it was a quirk of the MySQL version I was running. Maybe PDO checks the version number and tries to do some pre-processing or something. So I tried upgrading to MySQL 5.7 (the same version I have on the server where this code ran without issue). Upon upgrading, PHP started throwing a different error much earlier in the code base. Now I’m getting:
Allowed memory size of 134217728 bytes exhausted (tried to allocate 33554440 bytes)
Weird that I wasn’t running into this issue earlier… but I tried updating my
php.ini file. At least, I went to try it until I noticed that the
php.ini file had the
memory_limit set to -1! So it seemed like it either wasn’t loading my
php.ini file, or the
memory_limit was being overwritten afterwards.
A quick grep of my code revealed zero calls to
ini_set() and no instances of the string
memory_limit. So I checked to see that the config file was even being loaded:
stevendesu:~/workspace (master) $ php --ini | grep "Configuration File" Configuration File (php.ini) Path: /etc/php/7.0/cli Loaded Configuration File: (none)
So this is where I am now. PDO throws errors that the MySQL REPL doesn’t, and PHP is mysteriously failing to load a
php.ini file that exists and has its permissions configured properly. I don’t have similar issues on my own VM, so I can only assume this is somehow related to Cloud9’s file system and any related security settings.