Jump to content

SQL mode requirements for ProcessWire


Robin S
 Share

Recommended Posts

There have been a few issues raised here in the forums that seem to relate to SQL mode settings.

There is nothing stated on the requirements page about SQL mode but it seems that certain mode settings can cause problems, and maybe even settings that are now enabled by default in MySQL 5.7. Might be a question for @ryan, or does anyone else know:

What are the SQL mode requirements for ProcessWire?

 

  • Like 2
Link to comment
Share on other sites

In a related topic in the ProFields sub-forum @ryan has said:

Quote

I prefer not to have some SQL mode requirement, but instead to update any queries as needed to always work with whatever new versions of MySQL are defaulting to. We've had to update a few queries here and there over time as MySQL changes defaults in their versions. I think this is a good strategy to go with because changing the SQL mode may not always be an option depending on hosting environment.

So please log any SQL mode issues at GitHub as they arise so they can be tracked and resolved. :)

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 5 months later...
  • 2 years later...
On 8/9/2016 at 4:30 PM, Robin S said:

I prefer not to have some SQL mode requirement, but instead to update any queries as needed to always work with whatever new versions of MySQL are defaulting to. We've had to update a few queries here and there over time as MySQL changes defaults in their versions.

Interesting that Ryan said this when he actually decided to force removal (https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/config.php#L975) of the new mysql default for "ONLY_FULL_GROUP_BY", rather than properly rewriting the queries to work with the new default. 

 

  • Like 1
Link to comment
Share on other sites

As I understand it, „I prefer“ is not equal with „I never do“ or „I always do“.

A single decission may be a compromise related to: possibilities, „costs“, and possibly available manpower compared to expected time expenditure. 

?

  • Like 3
Link to comment
Share on other sites

1 hour ago, horst said:

A single decission may be a compromise related to: possibilities, „costs“, and possibly available manpower compared to expected time expenditure.

Agreed. ONLY_FULL_GROUP_BY can be quite tedious to work around, so that's a good candidate for an exception to the general rule. And, just for the reference, it's also one of the modes deemed incompatible with WordPress – so we're not the only ones who've decided that it's not worth it ?

  • Like 2
Link to comment
Share on other sites

5 hours ago, teppo said:

Agreed. ONLY_FULL_GROUP_BY can be quite tedious to work around

Yeah I know - I had a LOT of work to do to fix the queries on a large custom application of mine, but from the reading I did at the time, it was a highly recommended change to better ensure you're getting the results you were expecting. Mine was very data / calculation heavy though, so maybe not as important for typical PW queries.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...