sequelize you are using sql safe update error - mysql

I am getting this error randomly . I am deleting from activeusers table on the basis of username it gives me error sometime and works smoothly sometime.
here is my code for deleting
let say
data={nickname:'asad',id:1}
activeusers.destroy({where:{username:data.nickname} }).then(res=>{
});
I have turn off the sql safe update from sql workbench but problem still exists
how can i permanently get rid from this error

This is a common problem with updates in MySQL. Here is your query:
DELETE FROM ActiveUsers WHERE username = 'mazhar.hayat#ibexglobal.com'
The error stems from that you are not using a primary key column in the WHERE clause. You would also see this error if you had no WHERE clause at all. MySQL has a mode which views a DML query like this as unsafe, because it is broad and runs the risk of corrupting your data.
There is a hack solution to this which might work. You could modify the query to mention the primary key column as follows:
DELETE
FROM ActiveUser
WHERE username = 'mazhar.hayat#ibexglobal.com' AND id=id
This might spoof MySQL into thinking the query is safe, because it mentions the primary key column id in the WHERE clause.
But what I would recommend to you is turning off safe updates mode directly in MySQL. Edit your startup script and make sure that --safe-updates and --i-am-a-dummy are not mentioned in the script.
Edit:
If you wanted to handle this from destroy, then the query option is the only option:
Post.findAll(
{ where: ["username = ? AND id = id", data.nickname] }
).success()

Related

Why does MySQL safe update mode not allow a LIKE predicate?

Please consider the following scenario:
I have a MySQL table called actor. (Yes, it's from the Sakila sample DB).
In the table there's a varchar column called last_name.
There is a (non-PRIMARY) KEY on the column.
MySQL safe update mode is turned on.
When I run this query, it works:
DELETE FROM actor WHERE last_name = 'foo';
When I run this query:
DELETE FROM actor WHERE last_name LIKE '%fo' OR last_name LIKE 'fo%';
It fails with this error message:
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column. To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.
Why does safe update mode stop the second command and allow the first command?
According to the documentation:
It is possible for UPDATE and DELETE statements to produce an error in safe-updates mode even with a key specified in the WHERE clause, if the optimizer decides not to use the index on the key column.
A test like LIKE 'fo%' will normally use the index (the index can be used to match the beginning of a column), so it shouldn't cause the error. But a test like LIKE '%fo' cannot be indexed (it doesn't specify the beginning of the column, so a full scan is necessary), so you get an error.

Using Unique Indices versus Querying the Database

I am working on a login / registration system in node.js.
I usually query the database, to check whether the given username already exists, and if it doesn't, I create the new user.
I got the idea recently, of using the Unique Index in the MySQL database for the username. I have some questions though.
What would be the most efficient way to check for duplicates? Search the database for the given username, or use the Unique Index and catch an error from MySQL if it already exists?
I feel unsafe with MySQL spitting out errors when duplicates are made, but maybe I'm just crazy.
If I were to use the Unique Index, would it still be efficient to use it for every unique value? Such as having a Unique index for the username, email etc.?
What would be the most efficient way to check for duplicates? Search the database for the given username, or use the Unique Index and catch an error from MySQL if it already exists?
In first case you will be finding the user with username and then check whether it is found or not. So in this case your DB checks for this username and you also put one check.
Now consider second case where unique index is present. So you give mysql the data and it will try to check first and either throws the error or put the data into DB. This way you don't have to check double if the usrname is already in the DB or not. This will also save you from race conditions
If you are worrying about the mysql throwing errors then don't worry. mysql will throw an integrity error which you can catch and send appropriate response like username exists already
It's better to use Unique Indexes (with the validation occurring in the database engine), because this avoids thread races and ensures database integrity. Validating through select is unsafe and not a recommended way of doing it.
With that said, I recommend checking with a select before inserting to notify the user of the "username taken" before the tentative to insert.
Another good reason to use Unique Indexes is the performance. Depending on the size of the table, it can be way faster.

Where clause using key column still gives an error

I have a table that serves as a foreign key lookup from another table. The table is very simple, containing a ID column with is the primary key and a JSON column. I wish to remove abandoned entries from this table.
I tried running this script:
DELETE
FROM `ate`.`test_configuration`
WHERE `ate`.`test_configuration`.`ID` NOT IN (SELECT DISTINCT `ate`.`index`.`TestID` from `ate`.`index`);
But encountered an error stating my I wasn't using a where clause that uses the key column:
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.
This is confusing as my where clause does use the primary key column. I am aware that I can disable safe mode as part of my script as a workaround, but would still like to understand why I'm getting this error. I'd like to avoid unsafe updates if possible.
I believe Optimizer just unable to use index effectively for such query - so it does full table scan.
How many rows are in the test_configuration and how many of them will be deleted?
(You might try to use index hints to force optimizer to use index for the query, just not sure if they are supported in your version of mysql).

How to delete when primary key contains two columns, and using safe mode

My table is created like this:
CREATE TABLE test(
num1 INT,
num2 INT,
PRIMARY KEY(num1, num2)
);
what should my delete query look like?
using
DELETE FROM test WHERE num1=1 AND num2=2;
only result in this error message:
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect.
Also, before you ask, I do know how to turn safe update mode off, but that does not answer my question.
I've seen some other Stack Overflow posts where people complain that MySQL Workbench is blocking them from performing safe updates inappropriately.
But I just tried it with your table, both with the PK columns and with a non-key column. When safe mode is enabled, it blocks me from doing updates via non-key column, as it should. But I don't get the error you described.
I'm using MySQL Workbench 6.3.8 and MySQL Server 8.0.0-dmr.
Perhaps this is a bug in an old version of MySQL or an old version of MySQL Workbench.
Updated mysql and the error is gone.
what a waste of my time.

Why does MySQL think that I'm not using a WHERE statement?

I'm trying to update a table called rep in a database called premier_products. The table's primary key is rep_num.
When I run the following statement:
update rep
set last_name = "Perry"
where rep_num = 85;
I get an error that says "You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column."
I Googled that error message and most of the responses were along the lines of "You have to use a where clause or turn off safe mode". But as you can see, I am using a where clause. Why is the error appearing if I have a where clause?
MySQL server version 5.6.20.
This image shows that rep_num is definitely my primary key:
This image shows the current rep table:
Although you save only numbers, your primary-key type is char(2) and not tinyint(2) and when you update the record you are giving numerical value instead char value in your where condition. I think thats where the indexing mechanism triggers the error and tells you, your where condition is unsafe or might yield wrong results.
in your case try
update rep
set last_name = "Perry"
where rep_num = '85';
PS: why don't you name your tables with a prefix? like tbl_rep? just a thought.