mysql can not insert because no default value? - mysql

I have two tables with exactly the same schema. I can insert into one table but not another. The one that fails complains about no default value. Here's my create statement for the table
CREATE TABLE `t_product` (
`product_id` varchar(10) NOT NULL,
`prod_name` varchar(150) DEFAULT NULL,
`price` decimal(6,2) NOT NULL,
`prod_date` date NOT NULL,
`prod_meta` varchar(250) DEFAULT NULL,
`prod_key` varchar(250) DEFAULT NULL,
`prod_desc` varchar(150) DEFAULT NULL,
`prod_code` varchar(12) DEFAULT NULL,
`prod_price` decimal(6,2) NOT NULL,
`prod_on_promo` tinyint(1) unsigned NOT NULL,
`prod_promo_sdate` date DEFAULT NULL,
`prod_promo_edate` date DEFAULT NULL,
`prod_promo_price` decimal(6,2) NOT NULL,
`prod_discountable` tinyint(1) unsigned NOT NULL,
`prod_on_hold` tinyint(1) unsigned NOT NULL,
`prod_note` varchar(150) DEFAULT NULL,
`prod_alter` varchar(150) DEFAULT NULL,
`prod_extdesc` text,
`prod_img` varchar(5) NOT NULL,
`prod_min_qty` smallint(6) unsigned NOT NULL,
`prod_recent` tinyint(1) unsigned NOT NULL,
`prod_name_url` varchar(150) NOT NULL,
`upc_code` varchar(50) DEFAULT NULL,
PRIMARY KEY (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
When I run this statement in database1, it successfully inserts:
insert into t_product (product_id) values ('jlaihello');
When I run this exact statement in database2, I get the error:
ERROR 1364 (HY000): Field 'price' doesn't have a default value
Why is this error happening only in database2? As far as I can tell, the difference between database1 and database2 are:
database1 uses mysql Ver 14.14 Distrib 5.5.53, for debian-linux-gnu (i686) using readline 6.3
and
database2 uses mysql Ver 14.14 Distrib 5.7.16, for Linux (x86_64) using EditLine wrapper
How do I make database2 behave like database1?
EDIT
There are hundreds of tables affected by this. Basically we're moving a database over to a new server. And I did a mysqldump from db1, and imported into db2. t_product is just ONE of the tables affected by this. I'd like to avoid manually modifying the schema for the hundreds of tables. I prefer a "simple switch" that will make db2 behave like db1.

ERROR 1364 (HY000): Field 'price' doesn't have a default value
price decimal(6,2) NOT NULL,
Set price to null or assign a default value
EDIT:
This is caused by the STRICT_TRANS_TABLES SQL mode.
Open phpmyadmin and goto More Tab and select Variables submenu. Scroll down to find sql mode. Edit sql mode and remove STRICT_TRANS_TABLES Save it.
OR
You can run an SQL query within your database management tool, such as phpMyAdmin:
-- verify that the mode was previously set:
SELECT ##GLOBAL.sql_mode;
-- update mode:
SET ##GLOBAL.sql_mode= 'YOUR_VALUE';
OR
Find the line that looks like so in the mysql conf file:
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
Comment above line out and restart mysql server

Most probably, the default for column price is missing in the second database. To check this you should output your table structure:
describe database2.t_product;
OR
show create table database2.t_product;
and check if the default is defined.
You can alter your table and add the missing default constraint like this:
ALTER TABLE database2.t_product MODIFY COLUMN decimal(6,2) NOT NULL DEFAULT 0
EDIT
Based on comments and specification (data type default values), I think there is a difference in sql_mode of the MySQL:
For data entry into a NOT NULL column that has no explicit DEFAULT
clause, if an INSERT or REPLACE statement includes no value for the
column, or an UPDATE statement sets the column to NULL, MySQL handles
the column according to the SQL mode in effect at the time:
If strict SQL mode is enabled, an error occurs for transactional
tables and the statement is rolled back. For nontransactional tables,
an error occurs, but if this happens for the second or subsequent row
of a multiple-row statement, the preceding rows will have been
inserted.
If strict mode is not enabled, MySQL sets the column to the implicit
default value for the column data type.
So, if strict mode is not enabled for the first database, INSERT/UPDATE is allowed and storing the default value of that type (a 0 decimal)

Related

MariaDB: Unknown data type "MYSQL_JSON"

According to MariaDB's website, you can simply replace MySQL with MariaDB.
Great, I thought, however after installing MariaDB (10.5.7), some of my InnoDB tables are corrupt. The error is Unknown data type "MYSQL_JSON".
One of the corrupt tables also says "in use" in phpmyadmin, and I can't access it at all.
So, I was looking for a solution everywhere, and apparently MariaDB doesn't support that type. Is there any way to fix that? There must be some way to covert those columns, right?
I tried to downgrade back to MySQL 5.7, but now MySQL isn't working anymore, so I reinstalled MariaDB again. I couldn't find any downgrade guide either.
Here's a create table statement for the corrupt table, made from my local test-database. I was able to mysqldump all the other ones successfully. Just not this one. Granted, I have a backup from 1 day ago, but losing work from a whole day is not a nice thing regardless.
CREATE TABLE `news` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`author_id` int(10) unsigned DEFAULT NULL,
`title` varchar(180) COLLATE utf8mb4_unicode_ci NOT NULL,
`content` longtext COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`excerpt` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`sources` longtext COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '(DC2Type:json)',
`header` varchar(30) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`copyright` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`category` smallint(5) unsigned DEFAULT NULL,
`featured` tinyint(1) NOT NULL,
`language` smallint(5) unsigned NOT NULL,
`published` datetime DEFAULT NULL,
`status` smallint(5) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `IDX_1DD39950F675F31B` (`author_id`),
CONSTRAINT `FK_1DD39950F675F31B` FOREIGN KEY (`author_id`) REFERENCES `user` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=167 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
The table is auto-generated by Doctrine ORM.
If I could somehow get just a few rows of data out of that table, that would make my week. I just need the content column from the last day.
I got my system back running from my backup. Just those news are missing.
Update
I was able to find a .ibd file under /var/lib/mysql/{mydatabase}/ which contains all the data I needed in plain text. I'm just manually copying the content and insert it back into the database.
To fix Unknown data type "MYSQL_JSON" in the general case when migrating from MySQL to MariaDB.
You have 2 options.
Dump your database from MySQL and import it to MariaDB.
Fix all tables that have a JSON type column.
The first option is straightforward but to go with the second option as suggested by MariaDB website.
stop MySQL service if it is running
sudo service mysql stop
start a new mysql server instance
mysqld --no-defaults --datadir=<Your data dir directory> --lc-messages_dir=./share --plugin-dir=<path to directory containing type_mysql_json.so> --plugin-maturity=alpha
default datadir directory (mysql 5.7, ubuntu 18.04) is /var/lib/mysql/
default plugin directory is /usr/lib/mysql/plugin
while keeping the server running start a new MySQL command-line client and install mysql_json plugin.
install soname 'type_mysql_json';
Alter all tables that have a JSON type column.
ALTER TABLE `database_name`.`table_name` FORCE;
stop MySQL server instance and start MySQL service and everything should be fine.
ps: If you have lots of tables that contains JSON type column (as in my case) you can use this command to get list of all commands you have to run in order to fix all tables
SELECT CONCAT("ALTER TABLE `", TABLE_SCHEMA,"`.`", TABLE_NAME, "` FORCE;") AS MySQLCMD FROM TABLES WHERE TABLE_SCHEMA = "<YOUR_DATABASE_NAME>";
An in-place upgrade of the mysql-5.7 to MariaDB, for the JSON type requires a plugin to read its data format:
Add the following to your MariaDB server configuration:
plugin_load_add=mysql_json=type_mysql_json
plugin_maturity=alpha
Run mysql_upgrade --force to pick up all the JSON data types and convert them.
Alternately just ALTER TABLE news FORCE to change that one table.

Select query on MYSQL table taking long time and getting timed out

I have a mysql table with 2 million rows, when I'm running any select query on the table it's taking long time to execute and ultimately it does not return any result.
I have tried running select query from both Mysql Workbench and terminal, it's the same issue happening.
Below is the table:
`object_master`
`key` varchar(300) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`bucket` varchar(255) DEFAULT NULL,
`object_name` varchar(300) DEFAULT NULL,
`object_type` varchar(50) DEFAULT NULL,
`last_modified_date` datetime DEFAULT NULL,
`last_accessed_date` datetime DEFAULT NULL,
`is_deleted` tinyint(1) DEFAULT '0',
`p_object` varchar(300) DEFAULT NULL,
`record_insert_time` datetime DEFAULT CURRENT_TIMESTAMP,
`record_update_time` datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`key`)
ENGINE=InnoDB DEFAULT CHARSET=latin1
And below is the select query i'm running :
select `key` from object_master;
even with a limit 1 is also taking long time and not returning a result, its getting timed out :
select `key` from object_master limit 1;
Could anyone tell me what can be the real reason here?
Also I would like to mention: before I was running these select queries, there was an alter table statement executed on this table which got timed out after 10 minutes and table remained un-altered.
Following is the alter statement:
alter table object_master
modify column object_name varchar(1096) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL;
Note: Using MYSQL version 5.7.24 and Mysql running on Linux Docker container.
So I got this resolved:
There was Java batch program which was executing a query on the same table for long time and was holding a lock on the table. I found this through "processlist" table of information_schema.
Had to kill the long running query through terminal:
mysql> kill <processlist_id> ;
Then it released the lock on that table and all got resolved.
Got help from below SO answers:
Unlocking tables if thread is lost
How do I find which transaction is causing a "Waiting for table metadata lock" state?

Failed generated stored procedure

This is the code
CREATE TABLE `church` (
`ID` int(10) UNSIGNED NOT NULL,
`StudentID` int(11) NOT NULL,
`semesterID` int(11) NOT NULL,
`attendedWed` int(11) NOT NULL,
`attendedFri` int(11) NOT NULL,
`attendedSabM` int(11) NOT NULL,
`attendedSabE` int(11) NOT NULL,
`ChurchScore` double(10,2) GENERATED ALWAYS AS ((((((`attendedWed` + `attendedFri`) + `attendedSabM`) + `attendedSabE`) * 100) / 60)) STORED
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
This is the error
Operation failed: There was an error while applying the SQL script to
the database. Executing: ALTER TABLE citizenshipgroup3.church
CHANGE COLUMN ChurchScore ChurchScore DOUBLE(10,2) NULL DEFAULT
attendedWed ;
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 'attendedWed' at line 2 SQL Statement: ALTER TABLE
citizenshipgroup3.church CHANGE COLUMN ChurchScore
ChurchScore DOUBLE(10,2) NULL DEFAULT attendedWed
Your syntax is fine. The problem is that MySQL does not support generated columns until 5.7. You are presumably using an earlier version.
Probably the simplest solution is to use a view for the calculation.
The error appears at the time of ALTER TABLE, when you are trying to modify the column ChurchScore setting the DEFAULT value to an expression involving another Column attendedWed.
Also, your error message seems to be originating from MariaDB, not MySQL.
From Mariadb Documentation:
From MariaDB 10.2.1 you can use most functions in DEFAULT. Expressions
should have parentheses around them. If you use a non deterministic
function in DEFAULT then all inserts to the table will be replicated
in row mode. You can even refer to earlier columns in the DEFAULT
expression:
CREATE TABLE t1 (a int DEFAULT (1+1), b int DEFAULT (a+1));
CREATE TABLE t2 (a bigint primary key DEFAULT UUID_SHORT());
So you need to ensure couple of things:
Upgrade your MariaDB version to 10.2.1 and above. Preferably, upgrade to current latest version (it is 10.3+ right now).
You need to use parentheses around the expression specified in the DEFAULT clause.
So the ALTER TABLE statement would look like:
ALTER TABLE `citizenshipgroup3`.`church`
CHANGE COLUMN `ChurchScore` `ChurchScore` DOUBLE(10,2) NULL
DEFAULT (attendedWed) ;

how to make mysql database schema to be compatible with h2 database

I am currently using mysql as my database and use flyway to manage database schema. All my unit tests are running against mysql and they are running really slow with adding more unit tests. Now I want to change the database from mysql to h2 memory database in unit tests. Below is my setting for h2 db connection:
#Datasource
spring.datasource.url=jdbc:h2:mem:testDb;MVCC=TRUE;LOCK_TIMEOUT=10000;DB_CLOSE_ON_EXIT=FALSE;DATABASE_TO_UPPER=true
spring.datasource.username=
spring.datasource.password=
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.default-transaction-isolation-level=1
When I run flywayMigrate, I got some sql errors. Below is one example, this sql is used to create a table on mysql but failed to run on h2.
CREATE TABLE `file_storage` (
`id` BIGINT(64) NOT NULL AUTO_INCREMENT,
`file_name` VARCHAR(45) NULL,
PRIMARY KEY (`id`))
DEFAULT CHARACTER SET = utf8;
below is the error I got from h2. I don't know what wrong with my sql. Is there a way for h2 to accept mysql database schema?
Execution failed for task ':dbschema:flywayMigrate'.
> Error occurred while executing flywayMigrate
Migration V2016_02_26_12_59__create_file_storage.sql failed
-----------------------------------------------------------
SQL State : 42000
Error Code : 42000
Message : Syntax error in SQL statement "CREATE TABLE ""FILE_STORAGE"" (
""ID"" BIGINT(64) NOT NULL AUTO_INCREMENT,
""FILE_NAME"" VARCHAR(45) NULL,
PRIMARY KEY (""ID""))
DEFAULT CHARACTER[*] SET = UTF8 "; SQL statement:
CREATE TABLE `file_storage` (
`id` BIGINT(64) NOT NULL AUTO_INCREMENT,
`file_name` VARCHAR(45) NULL,
PRIMARY KEY (`id`))
DEFAULT CHARACTER SET = utf8 [42000-190]
Location : db/migration/V2016_02_26_12_59__create_file_storage.sql (/Users/yzzhao/dev/cooltoo/cooltoo_backend/dbschema/build/resources/main/db/migration/V2016_02_26_12_59__create_file_storage.sql)
Line : 1
Statement : CREATE TABLE `file_storage` (
`id` BIGINT(64) NOT NULL AUTO_INCREMENT,
`file_name` VARCHAR(45) NULL,
PRIMARY KEY (`id`))
DEFAULT CHARACTER SET = utf8
Syntax error in SQL statement "CREATE TABLE ""FILE_STORAGE"" (
""ID"" BIGINT(64) NOT NULL AUTO_INCREMENT,
""FILE_NAME"" VARCHAR(45) NULL,
PRIMARY KEY (""ID""))
DEFAULT CHARACTER[*] SET = UTF8 "; SQL statement:
CREATE TABLE `file_storage` (
`id` BIGINT(64) NOT NULL AUTO_INCREMENT,
`file_name` VARCHAR(45) NULL,
PRIMARY KEY (`id`))
DEFAULT CHARACTER SET = utf8 [42000-190]
EDIT
I have hundreds of sql scripts which is running fine in mysql. So I don't want to change anything in these scripts. Is there a way to allow h2 accepts mysql script?
According to this description, you may try to use your H2 database in MySQL Compatibility Mode, by setting it in the connection string as MODE=MySQL. Here is exactly what is said about it:
To use the MySQL mode, use the database URL jdbc:h2:~/test;MODE=MySQL or the SQL statement SET MODE MySQL.
When inserting data, if a column is defined to be NOT NULL and NULL is inserted, then a 0 (or empty string, or the current timestamp for timestamp columns) value is used. Usually, this operation is not allowed and an exception is thrown.
Creating indexes in the CREATE TABLE statement is allowed using INDEX(..) or KEY(..). Example: create table test(id int primary key, name varchar(255), key idx_name(name));
Meta data calls return identifiers in lower case.
When converting a floating point number to an integer, the fractional digits are not truncated, but the value is rounded.
Concatenating NULL with another value results in the other value.
Text comparison in MySQL is case insensitive by default, while in H2 it is case sensitive (as in most other databases). H2 does support case insensitive text comparison, but it needs to be set separately, using SET IGNORECASE TRUE. This affects comparison using =, LIKE, REGEXP.
Your issue can be seen with your example
CREATE TABLE `file_storage`
(
'id` BIGINT(64) NOT NULL AUTO_INCREMENT,
`file_name` VARCHAR(45) NULL,
PRIMARY KEY (`id`)
)
DEFAULT CHARACTER SET = utf8;
The last line "DEFAULT CHARACTER SET = utf8" is setting a mySQL table option. H2 does not have such an option at either the table or schema level as it operates using Unicode at all times.
If you have a lot of SQL DDL statements that have been written over the years for MySQL you are likely to see a lot of such issues.

MySql 5.7 Timestamp works in windows but not on linux

I am trying to create a table using the script down below and getting the error
Error Code: 1067. Invalid default value for 'LAST_MODIFIED_TS.
In my understanding after 5.6 you could create more than one timestamp column also it is not necessary to provide default values . Another thing is it is not barfing at Created_TS which is just one line before it.
Also the same script works on windows but not on linux ubuntu , the version of mysql running on both of them is 5.7
CREATE TABLE testdb.test (
ID BIGINT NOT NULL AUTO_INCREMENT,
DESCRIPTION VARCHAR(300) NOT NULL,
CREATED_TS TIMESTAMP NOT NULL,
LAST_MODIFIED_TS TIMESTAMP NOT NULL,
PROPERTY_TYPE VARCHAR(1) DEFAULT 'S',
last_modified timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
CONSTRAINT test_pk PRIMARY KEY
(ID) ) ENGINE=InnoDB ;
Make sure you don't have NO_ZERO_DATE sql_mode variable set (http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date) by running the following query:
show variables like 'sql_mode';