I am facing the following problem.
I have a table with this column:
`responsible_id` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '0',
From some reasons that have to do with the project, I cannot change this definition (NULL as default is not an option in this project).
I need to have this column UNIQUE, unless the value is 0.
Of course, I can do a check before I do INSERT/UPDATE from my php code, but constraints exist exactly to avoid this bad practice...
Any idea how to do it?
Existing:
CREATE TABLE tablename (
...
`responsible_id` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '0',
... );
Addition:
ALTER TABLE tablename
ADD COLUMN responsible_id_null VARCHAR(255) COLLATE utf8mb4_unicode_ci
GENERATED ALWAYS AS (NULLIF(responsible_id, '0')) /* STORED / VIRTUAL */,
ADD UNIQUE INDEX idx_responsible_id_null (responsible_id_null);
PS. Remember, that this may cause problems - for example, if somewhere SELECT * is used... or INSERT without columns list...
Could you edit and explain what's going on here, thanks :-) – Martin
I simply add generated column where '0' value is replaced with NULL value, and create unique index by this column (which will forbid duplicates but ignore/allow NULLs in generated column, i.e. forbid duplicates in source column but ignore/allow '0' in it).
Related
I have a table with a virtual generated column that concatenates five other columns (int and char) using CONCAT_WS(). This table contains 200-odd records and is never updated - it's just used as a lookup table. Recently, after months of untroubled processing, when I update records in a child table during which a SELECT is performed on this table, I sometimes see this error (ignore the "ITEM UPDATE FAILED" - that's me):
I am in development with a many changes every day, so it is impossible for me to determine if there is a correlating change. I have recently added "created" and "lastmodified" datetime fields to several tables with CURRENT_TIMESTAMP for DEFAULT or ON UPDATE, but not to this table.
Here's the table:
{EDIT} --- adding table definition:
CREATE TABLE `cpct_fixedfield` (
`id` int(11) UNSIGNED NOT NULL,
`name` varchar(256) NOT NULL,
`label` varchar(50) NOT NULL,
`field` int(11) NOT NULL,
`start` int(11) NOT NULL,
`rectype` int(11) NOT NULL ,
`mediatype` char(1) NOT NULL DEFAULT '' ,
`length` int(11) NOT NULL,
`userdefined` tinyint(1) NOT NULL,
`defaultval` varchar(5) NOT NULL,
`helpcode` varchar(10) NOT NULL,
`mandatory` varchar(2) NOT NULL ,
`idx` varchar(20) GENERATED ALWAYS AS (concat_ws('.',`field`,`rectype`,`mediatype`,`start`,`length`)) VIRTUAL NOT NULL)
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
The length of the data in field never exceeds 11chars. I can view the entire table in pma or Mysql Workbench and the virtual field materialises in all records without complaint, which suggests to me that there is nothing wrong with either the expression for the virtual column or the data in the columns that expression draws on.
The error occurs in several contexts when I am updating a child table. All the updates occur in Stored Procedures/Functions. One section of code that seems to trigger the error is this:
SET idxvar = CONCAT_WS(".", SUBSTRING(tmpfldkey,3,1), rectype, ptype, position, "%") COLLATE utf8mb4_general_ci;
SELECT id INTO ffid FROM cpct_fixedfield WHERE idx LIKE idxvar AND idx != "0.0..6.2";
All the variables involved are varchars or ints. utf8mb4_general_ci is used throughout the database.
I cannot find any reference in MYSQL documentation to CONCAT or CONCAT_WS being unsafe, and none of the columns referenced has a default using a non-deterministic function. All the other questions I can find in this forum and elsewhere about this error have arisen because of the use of non-deterministic functions like CURRENT_TIMESTAMP() in the virtual field, or a component of the field.
I replaced the SELECT on the table with a (large) CASE statement and all was well, and in fact, after I did this then reverted to the SELECT I had no errors for many hours. But it just happened again (so I'm back to the case statement).
I have run out of ideas - I'm hoping someone has some knowledge/experience that can help.
Thanks
I'm trying to create a table in phpMyAdmin, and I keep getting the same error no matter how I manipulate the SQL code. This is the preview SQL that phpMyAdmin generates
CREATE TABLE `puppies`.`animals` (
`id` INT(11) NOT NULL AUTO_INCREMENT ,
`puppy_name` VARCHAR(256) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
`breed_id` INT(11) NOT NULL ,
`description` VARCHAR(256) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
`price` DECIMAL(10,2) NOT NULL ,
`picture_url` VARCHAR(256) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
`sold` TINYINT(1) NOT NULL ,
PRIMARY KEY (`id`)
) ENGINE = InnoDB;
I've tried it with multiple variations of brackets and commas.
I have also faced the same issue and what I did was clicked on Preview SQL and copy the sql query and paste it in the SQL Run
To those still experiencing this, and don't want to wait for it to randomly work again:
I just encountered this, and cannot find any explanation other than some bug.
I tried:
CREATE TABLE `database`.`measurement_types` (
`TypeID` INT(2) NOT NULL AUTO_INCREMENT ,
`Name` VARCHAR(32) NOT NULL ,
`Description` VARCHAR(256) NOT NULL ,
PRIMARY KEY (`TypeID`)) ENGINE = InnoDB;
Which produced the same "Please enter valid length" error
Tried a few times with different length values, but kept getting the same error.
--SOLUTION--
So I just created the table with a single column first, then altered it with the two other columns like so:
CREATE TABLE `database`.`measurement_types` (
`TypeID` INT(2) NOT NULL AUTO_INCREMENT ,
PRIMARY KEY (`TypeID`)) ENGINE = InnoDB;
And then:
ALTER TABLE `measurement_types`
ADD `Name` VARCHAR(32) NOT NULL AFTER `TypeID`,
ADD `Description` VARCHAR(256) NOT NULL AFTER `Name`;
And that worked.
I also tried to delete the table and create it with the first SQL again, and this time it worked. Seems pretty random
I've had the same issue, seems to be a bug with VARCHAR fields. My solution was to make those fields INT, create the table, and then change them back to VARCHAR
You can also solve it by restarting your mysql... It worked for me.
It is a bug with varchar. If you change collation to utf8mb4_general_ci it should fix the problem
There seems to be some issue with PhpMyAdmin.
It needs 'Collation' value if column type is of varchar. You will encounter the error “Please enter a valid length” if the Collation field is empty for varchar. So basically both fields 'Size' and 'Collation' are mandatory and cannot be empty.
Please set Collation field with some value like 'utf8mb4_general_ci' to resolve the issue.
I solved the issue of "Please enter a valid length" by adding one by one column separately and by giving length to all the columns as the database needs to know how much memory it will consume.
It is definitely a problem with varchar fields but does not always happen.
You can still create your table by copying out the SQL query and executing the raw query.
As stated in the official docs, I think it is mandatory to give a specific length in later versions of phpMyAdmin.
I solved my “Please enter a valid length” by typing the length values for the data types that weren't of a dynamic memory allocation type. So therefore they obviously needed to know how much memory they could use for storage. Or by all means a valid length
If you use Varchar you have to give a length. Otherwise, it will not save.
My solution was to set a value for every varchar type.
I have been testing a database i am doing right now and i am noticing that it is letting me insert null values into fields that are part of a primary key, despite stating in the script that the value of the field should be NOT NULL. I am using MAC's MySQL Workbench, and I have been googling around and can't figure out why this is happening. (Maybe I am too brain-fried right now... I am even starting to doubt myself)
Part of the script of the database creation (these are the tables I have tested..):
DROP DATABASE IF EXISTS solytierra ;
CREATE DATABASE IF NOT EXISTS solytierra DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ;
USE solytierra ;
DROP TABLE IF EXISTS solytierra.Cliente ;
CREATE TABLE IF NOT EXISTS solytierra.Cliente (
CIF VARCHAR(25) NOT NULL,
Nombre VARCHAR(100) NULL,
EmailGeneral VARCHAR(45) NULL,
Web VARCHAR(45) NULL,
Notas VARCHAR(150) NULL,
insertado Timestamp,
CONSTRAINT pk_Cliente PRIMARY KEY (CIF)
) ENGINE=InnoDB;
DROP TABLE IF EXISTS solytierra.PersonaContacto ;
CREATE TABLE IF NOT EXISTS solytierra.PersonaContacto (
Cliente_CIF VARCHAR(25) NOT NULL,
Nombre VARCHAR(50) NOT NULL,
Apellidos VARCHAR(100) NOT NULL,
Notas VARCHAR(150) NULL,
CONSTRAINT pk_PersonaContacto PRIMARY KEY (Cliente_CIF , Nombre , Apellidos),
CONSTRAINT fk_PersonaContacto_Cliente FOREIGN KEY (Cliente_CIF)
REFERENCES solytierra.Cliente (CIF)
ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB;
...
It will let me create Clients without CIF, "PersonaContacto" without Cliente_CIF or without "Nombre"....
I have also tested other databases that i already had that used to work and it is happening the same in an all them.
Got it!!
I don't know what sql mode i was running on by default, but with this:
SET sql_mode = TRADITIONAL;
It is now running perfectly! I didn't know that there were different sql modes! Thanks a lot to everyone for your time and efforts! It really helped me to see that the problem was in my workbench, not the code and look for the answer accordingly! I hope this thread will be useful for future beginners like me!
If the value being stored in the column CIF is actually a NULL, then the expression LENGTH(CIF) should also return NULL. (If it's a zero length string, then LENGTH(CIF) will return 0.
To verify:
SELECT c.CIF, LENGTH(c.CIF) FROM solytierra.Cliente c ;
SELECT c.CIF FROM solytierra.Cliente c WHERE c.CIF IS NULL;
If you are running an INSERT statement, I can't explain the behavior you are observing, either MySQL allowing a NULL value to be stored or MySQL providing an implicit default value.)
If it's a zero length string being stored, that's the behavior we would expect if the columns were not explicitly declared to be NOT NULL but were later declared to part of the primary key. It's also the behavior we'd expect if the column were defined NOT NULL DEFAULT ''.
When the NOT NULL is omitted from the column declaration and the column is later declared to be part of the PRIMARY KEY, MySQL will use an an implicit default value based on the datatype of the column (zero length string for VARCHAR, zero for an integer, etc.)
But I'm not able to reproduce the problem you report, with the table definitions you've posted.
I recommend you check the table definition by getting the output from:
SHOW CREATE TABLE solytierra.Cliente;
Simplifying the database/table structure i have a situation with two tables where we store 'items' and item properties (the relation between the two is 1-N)
I'm trying to optimize the following query, which fetches latest items being in the hotdeals section. To do that we have item_property table which stores items sections along with many other item metadata
NOTE: table structure can't be changed to optimize the query, ie: we can't simply add the section as a column in the item table as we can have unlimited amount of sections for each item.
Here's the Structure of both tables:
CREATE TABLE `item` (
`iditem` int(11) unsigned NOT NULL AUTO_INCREMENT,
`itemname` varchar(200) NOT NULL,
`desc` text NOT NULL,
`ok` int(11) NOT NULL DEFAULT '10',
`date_created` datetime NOT NULL,
PRIMARY KEY (`iditem`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE TABLE `item_property` (
`iditem` int(11) unsigned NOT NULL,
`proptype` varchar(64) NOT NULL DEFAULT '',
`propvalue` varchar(200) NOT NULL DEFAULT '',
KEY `iditem` (`iditem`,`proptype`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
And here's the query:
SELECT *
FROM item
JOIN item_property ON item.iditem=item_property.iditem
WHERE
item.ok > 70
AND item_property.proptype='section'
AND item_property.propvalue = 'hotdeals'
ORDER BY item.date_created desc
LIMIT 20
Which would be the best indexes to optimize this query?
Right now the optimizer (Explain) will use temporary and filesort, processing a Ton of rows (the size of the join)
Tables are both MyIsam at the moment, but can be changed to InnoDB if its really necessary to optimize the queries
Thanks
What is the type of item_property.idOption and item_property.type columns?
If they contain a limited number of options - make them ENUM (if they are not already). Enum values are indexed automatically.
And (of course) you should have item_property.iditem and item.date_created columns indexed also. This will increase the size of the tables, but will considerably fasten the queries that join and sort by these fields.
A note about data correctness:
One of the big benefits of a NOT NULL is to prevent your program from creating a row that doesn't have all columns properly specified. Having a DEFAULT renders that useless.
Is it ever OK to have a blank proptype or propvalue? What does a blank in those fields mean? If it's OK to not have a proptype set, then remove the NOT NULL constraint. If you must always have a proptype set, then having DEFAULT '' will not save you from the case of inserting into the row but forgetting to set proptype.
In most cases, you want either NOT NULL or DEFAULT 'something' on your columns, but not both.
I currently trying to use an Object Relational Mapper for CodeIgniter and I'm experiencing something I did not expect.
I have a table with a couple of fields, some of which are NOT NULL. An insert query is which is missing of the NOT NULL fields is generated -- a new row is added but with blanks for those fields.
I did not know MySQL would disregard the NOT NULL fields that aren't present in the query and insert the row anyways. Is there a way to restrict this?
-Edit-
Let me add a few more details and try to explain it a bit more
Here is a sample table:
CREATE TABLE `test` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`color` varchar(40) COLLATE utf8_bin DEFAULT '',
`shape` varchar(40) COLLATE utf8_bin NOT NULL,
`size` varchar(40) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COLLATE=utf8_bin
Here is a sample query:
INSERT INTO `test` (`shape`) VALUES ('foo')
I don't have size in my query yet it still adds the row - is this expected?
(The sample query was run in phpMyAdmin)
I believe the accepted answer is incorrect, given the question's test INSERT statement. It looks to me like MySQL's "strict mode" is turned off for this table or database. From the docs:
Strict mode controls how MySQL handles input values that are invalid or missing... A value is missing when a new row to be inserted does not contain a value for a non-NULL column that has no explicit DEFAULT clause in its definition...
If you are not using strict mode (that is, neither STRICT_TRANS_TABLES nor STRICT_ALL_TABLES is enabled), MySQL inserts adjusted values for invalid or missing values and produces warnings.
You can find out how your database is running with these queries:
SELECT ##global.sql_mode;
SELECT ##session.sql_mode;
Changing these values is discussed here: https://stackoverflow.com/a/5273824/27846
Empty string is not the same thing as NULL. Perhaps ORM inserts just '' for those fields.
Not a codeigniter dev, but I would hazard a guess that the issue is your ORM is passing blank values on to the database, I would check your logs to verify this and if its the case, check your ORM if it has some validation options.