I have the following query builder:
$queryBuilder = $this
->createQueryBuilder('recipient')
->leftJoin('recipient.message', 'message')
->orderBy('message.dateSent', 'DESC');
This has been working fine :) - but since upgrading to Mysql 5.7 I have started getting this error everywhere:
SQLSTATE[HY000]:
General error: 3065
Expression #1 of ORDER BY clause is not in SELECT list, references column 'dctrn_result.date_sent_5' which is not in SELECT list;
this is incompatible with DISTINCT
I have solved this in most places where I am using the DBAL layer by just add the item to the select list, but I can't figure out how to do that with this particular queryBuilder.
You have to edit the /etc/mysql/mysql.cnf by adding these lines:
[mysqld]
sql-mode=""
Don't forget to restart the service mysql:
sudo service mysql restart
For info, I am using Ubuntu 16.04 LTS.
Adding:
[mysqld]
sql-mode=""
to /etc/mysql/my.cnf fixed the problem for me (after restarting service). Although of course an official response to the doctrine issue would be nicer.
Update: Someone who knows more than me about this recommended only disabling the mode that's causing the problem.
Actually mysql 5.7 contains 'ONLY_FULL_GROUP_BY' in sql mode.So we can't perform orderby in the element that is not in select list.we have to change it from
'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
into
'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
We can done this by executing the following queries
SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
Thanks,
Suriya
There is a bug reported in #4846 and it seems to be related to #sqlmode_only_full_group_by and there are some examples abaut what does it mean here. Until a proper fix comes out a solution would be to add ->addSelect('message') to the query (I don't know if it fixes the issue or doctrine rewrites the query anyway), but that way doctrine will hydrate massages as well which maybe not desired or disable ONLY_FULL_GROUP_BY sql mode, but then, mysql maybe can return invalid data.
When using QueryBuilder, joined tables are not added to the select list automatically. You can call addSelect(TABLE_ALIAS) to get rid of the error.
$queryBuilder = $this
->createQueryBuilder('recipient')
->leftJoin('recipient.message', 'message')
->addSelect('message') //THIS LINE
->orderBy('message.dateSent', 'DESC');
Updating Doctrine to 2.8 should resolve this.
Related
I have a big problem when I want to make a view.
CREATE VIEW AnneeBillet (ANNEE_BILLETS, CHIFFRES)
AS SELECT YEAR(FIN_RESERVATION), sum(TYPE.PRIX*NOMBRE)
FROM TYPE, BILLET
where TYPE.TYPE = BILLET.TYPE;
I have this error :
In aggregated query without GROUP BY, expression #1 of SELECT list
contains nonaggregated column 'parc.BILLET.FIN_RESERVATION'; this is
incompatible with sql_mode=only_full_group_by
I have already tried many solutions like putting
SET GLOBAL sql_mode=(SELECT REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY',''));
But I'm with a docker container and I've seen that I had to modify directly the configuration file to have what I want.
Then, I found this post on stackoverflow but I can't do
--sql_mode=(SELECT REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY',''))
in my docker-compose because I have an error like this :
mysql_1 | 2021-04-27T07:59:53.283400Z 0 [ERROR] [MY-000077]
[Server] /usr/sbin/mysqld: Error while setting value '(SELECT
REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY',''))' to 'sql_mode'.
Please help me, I'm fed up with this problem.
Just add GROUP BY YEAR(FIN_RESERVATION) to the end of your query or change it to MIN(YEAR(FIN_RESERVATION)) - you can also use max. If you didn't do these things and instead changed the mode MySQL would simply arbitrarily pick one of the year values anyway
Only full group by is a good thing
If you permanently want to disable only_full_group_by on startup, you can add:
sql-mode= "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"
To your my.ini or my.cnf under '[mysqld]'.
Also if you get the error:
"Error while setting value 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION' to 'sql_mode'"
as I did, you can get around this issue, by first clearing all sql-modes by putting sql-mode="" above:
sql-mode= "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"
You can't use an sql expression as the value of --sql_mode. Run SET SESSION sql_mode=(SELECT REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY','')); SELECT ##sql_mode; in your server and use the value it shows with --sql_mode.
I'm trying to query a secure bucket via couchbase CBQon windows.
I've got couchbase/bin in my PATH and from the command line I am able to run this:
cbq -engine=http://localhost:8091 -c=hug_contenthub:password
seems to connect OK:
Connected to : http://localhost:8091/. Type Ctrl-D or \QUIT to exit.
Path to history file for the shell : C:\Users\kevin\.cbq_history
cbq>_
From here on I can't do anything except quit. I tried several commands:
cbq> select 1=1
> SELECT DISTINCT type FROM `beer-sample`
> create primary index on `beer-sample`
They are all ignored. No feedback at all. The only thing that changes is cqb> becomes "....>" the cqb bit is stripped off.
What am I missing here?
I'm relatively new to Couchbase Server, and I'm used to the old MS SQL ways, and so I think I had a similar problem.
My solution: I added a 'semicolon' at the end of each query.
I also tend to prefer to use the new Query Workbench tool instead of cbq when I'm just writing and tweaking N1QL queries. (But maybe that's just me).
my Query :
select libelle,credit_initial,disponible_v,sum(montant) as montant
FROM fiche,annee,type where type.id_type=annee.id_type and annee.id_annee=fiche.id_annee
and annee = year(current_timestamp) GROUP BY libelle order by libelle asc
Mysql 5.7.9 runs the query without any problem but mysql 5.7.12
display the error above Could you please help me with that
I had a struggle getting this to work i've tested it and it's working on lamp server mysql version 5.12
So, steps to success:
sudo vim /etc/mysql/conf.d/mysql.cnf
Scroll to the bottom of file Copy and paste
[mysqld]
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
to the bottom of the file
save and exit input mode
sudo service mysql restart to restart MySQL.
Done!
This worked for me:
mysql -u root -p
mysql > SET GLOBAL sql_mode=(SELECT REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY',''));
You might need sudo for the first step:
sudo mysql -u root -p
You need to specify all of the columns that you're not using for an aggregation function in your GROUP BY clause like this:
select libelle,credit_initial,disponible_v,sum(montant) as montant
FROM fiche,annee,type where type.id_type=annee.id_type and annee.id_annee=fiche.id_annee
and annee = year(current_timestamp) GROUP BY libelle,credit_initial,disponible_v order by libelle asc
The full_group_by mode basically makes you write more idiomatic SQL. You can turn off this setting if you'd like. There are different ways to do this that are outlined in the MySQL Documentation. Here's MySQL's definition of what I said above:
MySQL 5.7.5 and up implements detection of functional dependence. If
the ONLY_FULL_GROUP_BY SQL mode is enabled (which it is by default),
MySQL rejects queries for which the select list, HAVING condition, or
ORDER BY list refer to nonaggregated columns that are neither named in
the GROUP BY clause nor are functionally dependent on them. (Before
5.7.5, MySQL does not detect functional dependency and ONLY_FULL_GROUP_BY is not enabled by default. For a description of
pre-5.7.5 behavior, see the MySQL 5.6 Reference Manual.)
You're getting the error because you're on a version < 5.7.5
You can disable
sql_mode=only_full_group_by
by some command you can try this by terminal or MySql IDE
mysql> set global sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
mysql> set session sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
I have tried this and worked for me.
Thanks :)
Solution 1: Remove ONLY_FULL_GROUP_BY from mysql console
mysql > SET GLOBAL sql_mode=(SELECT REPLACE(##sql_mode,'ONLY_FULL_GROUP_BY',''));
you can read more here
Solution 2: Remove ONLY_FULL_GROUP_BY from phpmyadmin
Open phpmyadmin & select localhost
Click on menu Variables & scroll down for sql mode
Click on edit button to change the values & remove ONLY_FULL_GROUP_BY & click on save.
You have to aggregate by anything NOT IN the group by clause.
So,there are two options...Add Credit_Initial and Disponible_v to the group by
OR
Change them to MAX( Credit_Initial ) as Credit_Initial, MAX( Disponible_v ) as Disponible_v if you know the values are constant anyhow and have no other impact.
Base ond defualt config of 5.7.5 ONLY_FULL_GROUP_BY
You should use all the not aggregate column in your group by
select libelle,credit_initial,disponible_v,sum(montant) as montant
FROM fiche,annee,type
where type.id_type=annee.id_type
and annee.id_annee=fiche.id_annee
and annee = year(current_timestamp)
GROUP BY libelle,credit_initial,disponible_v order by libelle asc
So let's fully understand, Let's say you have a query which works in localhost but does not in production mode, This is because in MySQL 5.7 and above they decided to activate the sql_mode=only_full_group_by by default, basically it is a strict mode which prevents you to select non aggregated fields.
Here's the query (works in local but not in production mode) :
SELECT post.*, YEAR(created_at) as year
FROM post
GROUP BY year
SELECT post.id, YEAR(created_at) as year // This will generate an error since there are many ids
FROM post
GROUP BY year
To verify if the sql_mode=only_full_group_by is activated for, you should execute the following query :
SELECT ##sql_mode; //localhost
Output : IGNORE_SPACE, STRICT_TRANS, ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
(If you don't see it, it means it is deactivated)
But if try in production mode, or somewhere where it gives you the error it should be activated:
SELECT ##sql_mode; //production
Output: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO...
And it's ONLY_FULL_GROUP_BY we're looking for here.
Otherwise, if you are using phpMyAdmin then go to -> Variables and search for sql_mode
Let's take our previous example and adapt it to it :
SELECT MIN(post.id), YEAR(created_at) as year //Here we are solving the problem with MIN()
FROM post
GROUP BY year
And the same for MAX()
And if we want all the IDs, we're going to need:
SELECT GROUP_CONCAT(post.id SEPARATOR ','), YEAR(created_at) as year
FROM post
GROUP BY year
or another newly added function:
SELECT ANY_VALUE(post.id), YEAR(created_at) as year
FROM post
GROUP BY year
⚠️ ANY_VALUE does not exist for MariaDB
And If you want all the fields, then you could use the same:
SELECT ANY_VALUE(post.id), ANY_VALUE(post.slug), ANY_VALUE(post.content) YEAR(created_at) as year
FROM post
GROUP BY year
❌ To deactivate the sql_mode=only_full_group_by then you'll need to execute this query:
SET GLOBAL sql_mode=(SELECT REPLACE(##sql_mode, 'ONLY_FULL_GROUP_BY', ''));
Sorry for the novel, hope it helps.
In Laravel, you just set false in file database.php.
...
'mysql' => [
...
'strict' => false,
...
]
Also if you use MySql 8+ try in console this command:
Open MySql console
mysql -u user_name -p
And set global SQL mode
SET GLOBAL sql_mode='STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_ENGINE_SUBSTITUTION';
Same thing is happened with 8.0+ versions as well. By default in 8.0+ version it is "enabled" by default. Here is the link official document reference
In case of 5.6+, 5.7+ versions, the property "ONLY_FULL_GROUP_BY" is disabled by default.
To disabled it, follow the same steps suggested by #Miloud BAKTETE
just go to the window bottom tray click on wamp icon ,click mysql->my.ini,then there is option ;sql-mode=""
uncomment this make it like sql-mode=""
and restart wamp
worked for me
I have the following code that run on heroku inside a controller that intermittently fails. It's a no-brainer that it should work to me, but I must be missing something.
#artist = Artist.find(params[:artist_id])
The parameters hash looks like this:
{"utf8"=>"������",
"authenticity_token"=>"XXXXXXXXXXXXXXX",
"password"=>"[FILTERED]",
"commit"=>"Download",
"action"=>"show",
"controller"=>"albums",
"artist_id"=>"62",
"id"=>"157"}
The error I get looks like this:
ActiveRecord::StatementInvalid: Mysql::Error: : SELECT `artists`.* FROM `artists` WHERE `artists`.`id` = ? LIMIT 1
notice the WHEREartists.id= ? part of the statement? It's trying to find an ID of QUESTION MARK. Meaning Rails is not passing in the params[:artist_id] which is obviously in the params hash. I'm at complete loss.
I get the same error on different pages trying to select the record in a similar fashion.
My environment: Cedar Stack on Heroku (this only happens on Heroku), Ruby 1.9.3, Rails 3.2.8, files being hosted on Amazon S3 (though I doubt it matters), using the mysql gem (not mysql2, which doesn't work at all), ClearDB MySQL database.
Here's the full trace.
Any help would be tremendously appreciated.
try sql?
If it's just this one statement, and it's causing production problems, can you omit the query generator just for now? In other words, for very short term, just write the SQL yourself. This will buy you a bit of time.
# All on one line:
Artist.find_by_sql
"SELECT `artists`.* FROM `artists`
WHERE `artists`.`id` = #{params[:artist_id].to_i} LIMIT 1"
ARel/MySQL explain?
Rails can help explain what MySQL is trying to do:
Artist.find(params[:artist_id]).explain
http://weblog.rubyonrails.org/2011/12/6/what-s-new-in-edge-rails-explain/
Perhaps you can discover some kind of difference between the queries that are succeeding vs. failing, such as how the explain uses indexes or optimizations.
mysql2 gem?
Can you try changing from the mysql gem to the mysql2 gem? What failure do you get when you switch to the mysql2 gem?
volatility?
Perhaps there's something else changing the params hash on the fly, so you see it when you print it, but it's changed by the time the query runs?
Try assigning the variable as soon as you receive the params:
artist_id = params[:artist_id]
... whatever code here...
#artist = Artist.find(artist_id)
not the params hash?
You wrote "Meaning Rails is not passing in the params[:artist_id] which is obviously in the params hash." I don't think that's the problem-- I expect that you're seeing this because Rails is using the "?" as a placeholder for a prepared statement.
To find out, run the commands suggested by #Mori and compare them; they should be the same.
Article.find(42).to_sql
Article.find(params[:artist_id]).to_sql
prepared statements?
Could be a prepared statement cache problem, when the query is actually executed.
Here's the code that is failing-- and there's a big fat warning.
begin
stmt.execute(*binds.map { |col, val| type_cast(val, col) })
rescue Mysql::Error => e
# Older versions of MySQL leave the prepared statement in a bad
# place when an error occurs. To support older mysql versions, we
# need to close the statement and delete the statement from the
# cache.
stmt.close
#statements.delete sql
raise e
end
Try configuring your database to turn off prepared statements, to see if that makes a difference.
In your ./config/database.yml file:
production:
adapter: mysql
prepared_statements: false
...
bugs with prepared statements?
There may be a problem with Rails ignoring this setting. If you want to know a lot more about it, see this discussion and bug fix by Jeremey Cole and Aaron: https://github.com/rails/rails/pull/7042
Heroku may ignore the setting. Here's a way you can try overriding Heroku by patching the prepared_statements setup: https://github.com/rails/rails/issues/5297
remove the query cache?
Try removing the ActiveRecord QueryCache to see if that makes a difference:
config.middleware.delete ActiveRecord::QueryCache
http://edgeguides.rubyonrails.org/configuring.html#configuring-middle
try postgres?
If you can try Postgres, that could clear it up too. That may not be a long term solution for you, but it would isolate the problem to MySQL.
The MySQL statement is obviously wrong, but the Ruby code you mentioned would not produce it. Something is wrong here, either you use a different Ruby code (maybe one from a before_filter) or pass a different parameter (like params[:artist_id] = "?"). Looks like you use nested resources, something like Artist has_many :albums. Maybe the #artist variable is not initialized correctly in the previous action, so that params[:artist_id] has not the right value?
hi there i made track star application and everything works fine except for one issue that i face error
CDbCommand failed to execute the SQL statement: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'devnmark_root.AuthAssignment' doesn't exist. The SQL statement executed was: SELECT *
FROM 'AuthAssignment'
WHERE userid=:userid
now this was automatically generated by Yii when i checked for if(Yii::app()->user->checkAccess('createUser',array('project'=>$model)))
18 {
19 $this->menu[] = array('label'=>'Add User To Project','url'=>array('adduser', 'id'=>$model->id));
20 }
then i went to phpmyadmin and executed this query manually
SELECT * FROMAuthAssignmentWHERE userid=4 and there is error which says same that table does not exist.
if i use small case letter for table name then no error.
i executed same query on local wamp 's phpmyadmin same query does not show any error there so this is clear that there is error with my sql .any idea what can i do to solve?
I suggest you hitting up SQL_MODE documentation for setting your final options. http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html
For testing you can just do a:
SET sql_mode = '';
Or adjust your command line:
--sql-mode=""
You may try to set the system variable *lower_case_table_names* to 1.
My local application was developed under Windows, howerver production is under Linux and I caused the same problem.
For me it happened because of case sensitivity - table AuthAssignment in database was actually authassignment.
I have found two options to solve it:
rename database table from authassignment to AuthAssignment
or
edit config file component section:
'components'=>array(
...
'user'=>array(...
),
'authManager'=>array(
...
'assignmentTable'=>'authassignment' //THIS LINE SOLVED MY PROBLEM
),
I had the same problem of non-existent authassignment table, I had forgotten running the rights installation which in my case was by following URL i.e.
/index.php/rights/install
and then the setup was like a breeze and self explanatory :)
For me this answer helped the most: original source.
In the authManager in config/main.php you can add lowercased names of the tables like this:
'components'=>array(
'authManager'=>array(
'defaultRoles'=>array('guest'),
'class'=>'RDbAuthManager',
'assignmentTable'=>'authassignment',
'itemTable'=>'authitem',
'rightsTable'=>'rights',
'itemChildTable'=>'authitemchild',
),