After fixing Error 1253 (MySQL: Unable to fulling forward engineering Sakila (sample) into server), I have Error 1628.
Executing SQL script in server
ERROR: Error 1628: Comment for table 'customer' is too long (max = 60)
Scripts:
CREATE TABLE IF NOT EXISTS `sakila`.`customer` (
`customer_id` SMALLINT(5) UNSIGNED NOT NULL AUTO_INCREMENT ,
`store_id` TINYINT(3) UNSIGNED NOT NULL ,
`first_name` VARCHAR(45) NOT NULL ,
`last_name` VARCHAR(45) NOT NULL ,
`email` VARCHAR(50) NULL DEFAULT NULL ,
`address_id` SMALLINT(5) UNSIGNED NOT NULL ,
`active` TINYINT(1) NOT NULL DEFAULT TRUE ,
`create_date` DATETIME NOT NULL ,
`last_update` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ,
PRIMARY KEY (`customer_id`) ,
INDEX `idx_fk_store_id` (`store_id` ASC) ,
INDEX `idx_fk_address_id` (`address_id` ASC) ,
INDEX `idx_last_name` (`last_name` ASC) ,
CONSTRAINT `fk_customer_address`
FOREIGN KEY (`address_id` )
REFERENCES `sakila`.`address` (`address_id` )
ON DELETE RESTRICT
ON UPDATE CASCADE,
CONSTRAINT `fk_customer_store`
FOREIGN KEY (`store_id` )
REFERENCES `sakila`.`store` (`store_id` )
ON DELETE RESTRICT
ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COMMENT 'Table storing all customers. Holds foreign keys to the address table and the store table where this customer is registered.\n\nBasic information about the customer like first and last name are stored in the table itself. Same for the date the record was created and when the information was last updated.'
SQL script execution finished: statements: 3 succeeded, 1 failed
As an addition: More current versions (5.6.X) allow longer comments. Unfortunately this length differs from the type of comment:
For tables: "A comment for the table, up to 2048 characters long."
For columns: "A comment for a column can be specified with the COMMENT option, up to 1024 characters long."
For INDEX: "In MySQL 5.6, index definitions can include an optional comment of up to 1024 characters."
For PARTITION: "Beginning with MySQL 5.6.6, the maximum length for a partition comment is 1024 characters. (Previously, this limit was not explicitly defined.)"
Source: http://dev.mysql.com/doc/refman/5.6/en/create-table.html
As stated in the MySQL docs, a comment is limited to 255 characters: http://dev.mysql.com/doc/refman/5.1/en/create-table.html#id3411882. Your comment is 305 characters, and it would seem, from the error message, that your particular MySQL install has a 60 character limit.
Related
I discovered the normal 3072 byte key limitation in MariaDB 10.3 while running this statement:
ALTER TABLE table1 ADD UNIQUE INDEX idx_my_composite_uniqueai_usr_email_uniq (table2_uuid ASC, table3_uuid ASC, text_column ASC)
Which gave the expected error:
ERROR 1071 (42000) at line 31: Specified key was too long; max key length is 3072 bytes
DDL for table1:
CREATE TABLE table1
(
uuid char(36) CHARACTER SET ascii NOT NULL,
table2_fk_uuid char(36) CHARACTER SET ascii NOT NULL,
table3_fk_uuid char(36) CHARACTER SET ascii NOT NULL,
text_field varchar(1024) DEFAULT NULL,
PRIMARY KEY (uuid),
KEY fk_table2_fk_uuid (table2_fk_uuid),
KEY fk_table3_fk_uuid (table3_fk_uuid),
CONSTRAINT fk_table1_table2 FOREIGN KEY (table2_uuid) REFERENCES table2 (uuid) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT fk_table1_table3 FOREIGN KEY (table3_uuid) REFERENCES table3 (uuid) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
My understanding is that the total key length for this unique key is 1024 * 4 (because text_field column is CHARSET=utfmb3) + 36 * 2 = 4168 bytes.
I realize that shortening the text_field column width if possible is the best way to stay within the key length limitation. However, prior to understanding this I upgraded my MariaDB server to 10.5 and also to 10.6 and the ALTER TABLE command executes just fine and the key is created.
Has the key limitation been expanded in the later db version? I'm not see that it did in the MariaDB documentation. If not, what else am I missing?
The limitation was removed back in 10.4. Release notes mention it :
"Unique indexes can be created on BLOB or TEXT fields (MDEV-371)"
I have a lot of existing records which I want to copy using an INSERT, for example if I have a query:
SELECT * FROM `threats` WHERE biDataset=9;
The common key is biDataset, the primary key in this table is biPK which is auto incremented on each insert. Here is the table structure:
CREATE TABLE `threats` (
`biPK` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'Primary key',
`biDataset` BIGINT(20) UNSIGNED NOT NULL COMMENT 'ID of dataset',
`jsonParams` LONGTEXT NOT NULL COMMENT 'JSON object containing all parameters' COLLATE 'utf8mb4_bin',
`txtTrainee` MEDIUMTEXT NULL DEFAULT NULL COMMENT 'Trainee host name (NULL if not applicable)' COLLATE 'utf8mb4_unicode_ci',
PRIMARY KEY (`biPK`) USING BTREE,
UNIQUE INDEX `dataset and json` (`biDataset`, `jsonParams`) USING HASH,
INDEX `datasetIdx` (`biDataset`) USING BTREE,
INDEX `jsonIdx` (`jsonParams`(768)) USING BTREE
)
COMMENT='Table of datasets'
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB
AUTO_INCREMENT=174;
What I want to do is copy all the records that exist where biDataset is 9, creating new records, I need to be able to specify the new biDataset too, 15 to use for all copies instead of 9.
I've tried:
INSERT INTO `threats` (biDataset, txtTrainee, jsonParams)
SELECT 15, NULL, jsonParams FROM `threats` WHERE biDataset=9;
This results in:
SQL Error (1364): Field 'DB_ROW_HASH_1' doesn't have a default value
The solution was to modify the table structure to:
CREATE TABLE `threats` (
`biPK` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'Primary key',
`biDataset` BIGINT(20) UNSIGNED NULL DEFAULT NULL COMMENT 'ID of dataset',
`jsonParams` LONGTEXT NULL DEFAULT NULL COMMENT 'JSON object containing all parameters' COLLATE 'utf8mb4_bin',
`txtTrainee` MEDIUMTEXT NULL DEFAULT NULL COMMENT 'Trainee host name (NULL if not applicable)' COLLATE 'utf8mb4_unicode_ci',
PRIMARY KEY (`biPK`) USING BTREE,
UNIQUE INDEX `dataset and json` (`biDataset`, `jsonParams`) USING HASH,
INDEX `datasetIdx` (`biDataset`) USING BTREE,
INDEX `jsonIdx` (`jsonParams`(768)) USING BTREE
)
COMMENT='Table of datasets'
COLLATE='utf8mb4_unicode_ci'
ENGINE=InnoDB
AUTO_INCREMENT=174
;
This is bug of mariadb, and it is still unresolved...
Checkout: https://jira.mariadb.org/browse/MDEV-22756
I am experimenting with PostgreSQL coming from SQL using MySQL and I simply wish to create a table with this piece of code which is valid SQL:
CREATE TABLE flat_10
(
pk_flat_id INT(30) DEFAULT 1,
rooms INT(10) UNSIGNED NOT NULL,
room_label CHAR(1) NOT NULL,
PRIMARY KEY (flat_id)
);
I get the error
ERROR: syntax error at or near "("
LINE 3: pk_flat_id integer(30) DEFAULT 1,
I have conducted searches on the web and found no answer and I cant seem to find an answer in the PostgreSQL manual. What am I doing wrong?
I explicitly want to set a limit to the number of digits that can be inserted into the "pk_flat_id" field
I explicitly want to set a limit to the number of digits that can be inserted into the "pk_flat_id" field
Your current table definition does not impose a "size limit" in any way. In MySQL the parameter for the intdata type is only a hint for applications on the display width of the column when displaying it.
You can store the value 2147483647 in an int(1) without any problems.
If you want to limit the values to be stored in an integer column you can use a check constraint:
CREATE TABLE flat_10
(
pk_flat_id bigint DEFAULT 1,
rooms integer NOT NULL,
room_label CHAR(1) NOT NULL,
PRIMARY KEY (flat_id),
constraint valid_number
check (pk_flat_id <= 999999999)
);
The answer is that you use numeric or decimal types. These are documented here.
Note that these types can take an optional precision argument, but you don't want that. So:
CREATE TABLE flat_10
(
pk_flat_id DECIMAL(30) DEFAULT 1,
rooms DECIMAL(10) NOT NULL,
room_label CHAR(1) NOT NULL,
PRIMARY KEY (pk_flat_id)
);
Here is a SQL Fiddle.
I don't think that Postgres supports unsigned decimals. And, it seems like you really want serial types for your keys and the long number of digits is superfluous.
Changing integer to numeric works.
CREATE TABLE flat_10
(
pk_flat_id bigint DEFAULT 1,
rooms numeric NOT NULL,
room_label CHAR(1) NOT NULL,
);
I was trying to run following Query on my sql server :
CREATE TABLE `e_store`.`products`(
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
`name` VARCHAR(250) NOT NULL ,
`brand_id` INT UNSIGNED NOT NULL ,
`category_id` INT UNSIGNED NOT NULL ,
`attributes` JSON NOT NULL ,
PRIMARY KEY(`id`) ,
INDEX `CATEGORY_ID`(`category_id` ASC) ,
INDEX `BRAND_ID`(`brand_id` ASC) ,
CONSTRAINT `brand_id` FOREIGN KEY(`brand_id`) REFERENCES `e_store`.`brands`(`id`) ON DELETE RESTRICT ON UPDATE CASCADE ,
CONSTRAINT `category_id` FOREIGN KEY(`category_id`) REFERENCES `e_store`.`categories`(`id`) ON DELETE RESTRICT ON UPDATE CASCADE
);
I have already brands and categories tables on my e_store database.
But I got the following Error :
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'JSON NOT NULL ,
PRIMARY KEY(`id`) ,
INDEX `CATEGORY_ID`('category_id' ' at line 6
For those who are facing this issue similar to me:
MariaDB does not natively implement the JSON data type but it uses it as an alias for LONGTEXT for compatibility reasons. According to the documentation (https://mariadb.com/kb/en/library/json-data-type/):
JSON is an alias for LONGTEXT introduced for compatibility reasons with MySQL's JSON data type. MariaDB implements this as a LONGTEXT rather, as the JSON data type contradicts the SQL standard, and MariaDB's benchmarks indicate that performance is at least equivalent.
In order to ensure that a a valid json document is inserted, the JSON_VALID function can be used as a CHECK constraint.
So if you are having issues with the JSON data type in MariaDB, simply just change to LONGTEXT. ;-)
I think you are getting error for JSON datatype.
For Mysql 5.7 you can get help from below link.
https://dev.mysql.com/doc/refman/5.7/en/json.html
You can check vesrion using below query.
select version() as 'mysql version'
"JSON" is parsed in the server. JSON is one of the points of divergence.
MySQL 5.7 introduced the JSON datatype, which matches your syntax.
MariaDB 10.0.16 introduced a ENGINE=CONNECT table_type=JSON which does not match your attempted syntax.
You have given single quotes in your index definitions instead of backticks
Try this:
CREATE TABLE `e_store`.`products`(
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
`name` VARCHAR(250) NOT NULL ,
`brand_id` INT UNSIGNED NOT NULL ,
`category_id` INT UNSIGNED NOT NULL ,
`attributes` JSON NOT NULL ,
PRIMARY KEY(`id`) ,
INDEX `CATEGORY_ID`(`category_id` ASC) , -- Changed single quotes to backticks
INDEX `BRAND_ID`(`brand_id` ASC) , -- Changed single quotes to backticks
CONSTRAINT `brand_id` FOREIGN KEY(`brand_id`) REFERENCES `e_store`.`brands`(`id`) ON DELETE RESTRICT ON UPDATE CASCADE ,
CONSTRAINT `category_id` FOREIGN KEY(`category_id`) REFERENCES `e_store`.`categories`(`id`) ON DELETE RESTRICT ON UPDATE CASCADE
);
I am experimenting with PostgreSQL coming from SQL using MySQL and I simply wish to create a table with this piece of code which is valid SQL:
CREATE TABLE flat_10
(
pk_flat_id INT(30) DEFAULT 1,
rooms INT(10) UNSIGNED NOT NULL,
room_label CHAR(1) NOT NULL,
PRIMARY KEY (flat_id)
);
I get the error
ERROR: syntax error at or near "("
LINE 3: pk_flat_id integer(30) DEFAULT 1,
I have conducted searches on the web and found no answer and I cant seem to find an answer in the PostgreSQL manual. What am I doing wrong?
I explicitly want to set a limit to the number of digits that can be inserted into the "pk_flat_id" field
I explicitly want to set a limit to the number of digits that can be inserted into the "pk_flat_id" field
Your current table definition does not impose a "size limit" in any way. In MySQL the parameter for the intdata type is only a hint for applications on the display width of the column when displaying it.
You can store the value 2147483647 in an int(1) without any problems.
If you want to limit the values to be stored in an integer column you can use a check constraint:
CREATE TABLE flat_10
(
pk_flat_id bigint DEFAULT 1,
rooms integer NOT NULL,
room_label CHAR(1) NOT NULL,
PRIMARY KEY (flat_id),
constraint valid_number
check (pk_flat_id <= 999999999)
);
The answer is that you use numeric or decimal types. These are documented here.
Note that these types can take an optional precision argument, but you don't want that. So:
CREATE TABLE flat_10
(
pk_flat_id DECIMAL(30) DEFAULT 1,
rooms DECIMAL(10) NOT NULL,
room_label CHAR(1) NOT NULL,
PRIMARY KEY (pk_flat_id)
);
Here is a SQL Fiddle.
I don't think that Postgres supports unsigned decimals. And, it seems like you really want serial types for your keys and the long number of digits is superfluous.
Changing integer to numeric works.
CREATE TABLE flat_10
(
pk_flat_id bigint DEFAULT 1,
rooms numeric NOT NULL,
room_label CHAR(1) NOT NULL,
);