Issue with SQL statement in MySQL and MariaDB
I have the below SQL statement which works as expected on my local machine WAMP server using MySQL, but when I upload to the live server using MariaDB, it doesn't work as expected anymore. The SQL statement is used for post and comment display. Any post or comment with latest postdate should be on top of the displayed list. As I said, it worked perfectly with MySQL on my local WAMP server, but when I upload to live server using MariaDB, no matter what I tried, it reverses the order by showing latest post/comment at the bottom of the list and old post/comments at the top. Please help me as I'm now confused on why it's behaving this way.
The SQL statement is shown below:
The SQL statement is shown below:
SELECT * FROM
(SELECT once.id, message, audio, audio_desc, accepted, postdate, tag, broadcast, once.mobile, once.username1, state, users.username, users.firstname, users.lastname, users.fullname, users.avatar, users.alias, useroptions.aliascheck, content_provider.content_type, comment.comment_date as c1 FROM once LEFT OUTER JOIN users ON once.username1 = users.username INNER JOIN useroptions ON once.username1 = useroptions.username LEFT OUTER JOIN content_provider ON once.username1 = content_provider.provider LEFT JOIN comment ON once.id = comment.post_id AND once.tag = comment.post_tag WHERE once.username1='logusername' OR once.username1='myusername'
UNION ALL
SELECT daily.id, message, audio, audio_desc, accepted, postdate, tag, broadcast, daily.mobile, daily.username1, state, users.username, users.firstname, users.lastname, users.fullname, users.avatar, users.alias, useroptions.aliascheck, content_provider.content_type, comment.comment_date as c1 FROM daily LEFT OUTER JOIN users ON daily.username1 = users.username INNER JOIN useroptions ON daily.username1 = useroptions.username LEFT OUTER JOIN content_provider ON daily.username1 = content_provider.provider LEFT JOIN comment ON daily.id = comment.post_id AND daily.tag = comment.post_tag WHERE daily.username1='logusername' OR daily.username1='myusername'
UNION ALL
SELECT weekly.id, message, audio, audio_desc, accepted, postdate, tag, broadcast, weekly.mobile, weekly.username1, state, users.username, users.firstname, users.lastname, users.fullname, users.avatar, users.alias, useroptions.aliascheck, content_provider.content_type, comment.comment_date as c1 FROM weekly LEFT OUTER JOIN users ON weekly.username1 = users.username INNER JOIN useroptions ON weekly.username1 = useroptions.username LEFT OUTER JOIN content_provider ON weekly.username1 = content_provider.provider LEFT JOIN comment ON weekly.id = comment.post_id AND weekly.tag = comment.post_tag WHERE weekly.username1='logusername' OR weekly.username1='myusername') outerQueryName GROUP BY id ORDER BY COALESCE(GREATEST(postdate, MAX(c1)), postdate) DESC
GROUP BY
Here, because you are NOT using any aggregations, you can achieve unique rows by using "select distinct" (if really necessary).
[edit]
with the advent of MySQL 8 using the window function row_number() may become useful to you (to get just the most recent rows). row_number() has been available in MariaDB for some time now, but is quite recent for MySQL.
MySQL introduced a really bad idea. It has led folk to believe that you only need to have one or a few columns in a group by clause, and as if by magic that the remaining columns will sort themselves out. Like most magic, this is an allusion. To avoid this problem repeat all "non-aggregating" columns of the select clause into the group by clause.
Ste5an has (correctly) pointed out that the only_full_group_by setting is probably different in the 2 environments, but I would add that even if they are changed to be the same, you still need to avoid this pitfall. Always use all "non-aggregating" columns of a select clause in the group by clause.
(If there is a "deterministic" relationship strictly speaking this isn't needed, but as most of us never know if it is fully "deterministic" or not, the safe approach is to specify all grouping columns.)
Ste5an has (correctly) pointed out that the only_full_group_by setting is probably different in the 2 environments, but I would add that even if they are changed to be the same, you still need to avoid this pitfall. Always use all "non-aggregating" columns of a select clause in the group by clause.
(If there is a "deterministic" relationship strictly speaking this isn't needed, but as most of us never know if it is fully "deterministic" or not, the safe approach is to specify all grouping columns.)
Here, because you are NOT using any aggregations, you can achieve unique rows by using "select distinct" (if really necessary).
[edit]
with the advent of MySQL 8 using the window function row_number() may become useful to you (to get just the most recent rows). row_number() has been available in MariaDB for some time now, but is quite recent for MySQL.
ASKER
@Ste5an, how do I do that? I'm a novice when it comes to databases.
@PortLetPaul I'm confused the more now with your explanation. Please can you just give a correct SQL statement that would work on mariadb?
@PortLetPaul I'm confused the more now with your explanation. Please can you just give a correct SQL statement that would work on mariadb?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks PortletPaul, that works as expected.
Great, pleased we could help.
Also I'm not sure whether your GROUP BY/ORDER BY can be deterministic at all.