I've been upgrading a website from Mysql 5.6 to 5.7. When restoring a backup from mysqldump, which has worked for 10 years (unchanged) under Mysql 5.1-5.6, it no longer works under MySQL 5.7.
Specifically, the first row of geometry data fails the restore:
ERROR 1416 (22003) at line 1580 Cannot get geometry object from data you send to the GEOMETRY field
So, this is valid geometry, but not any more.
Remedies attempted:
Switch mysqldump to --hex-blob
Try using astext( <some geometry> ) before importing
Tired hand loading various geometry rows from the backup, all fail
It looks like MySQL 5.7 is more strict in Geometry types than MySQL 5.6. As such, data that was valid in 5.6 is now invalid in 5.7.
This was the fix to MySQL Bug #76337, in release MySQL 5.7.8.
In this case, a LINESTRING was being stored in a column of type POINT. This worked for nearly a decade, but no more. Changing the column to type LINESTRING fixed the above loading error.
-- The Fix - run on MySQL 5.6 database before Upgrade/Export
ALTER TABLE routes MODIFY COLUMN route_path LINESTRING;
Other Failure Modes
This bug also manifest on geometric columns where they were able to persist NULL geometries (but not being officially NULL). MySQL IS NULL would say not null, but asText( myGeo ) returned NULL under MySQL 5.7. Exporting these to a string in MySQL 5.6 returned '', empty string. Thus the '' geometry output from 5.6 was and invalid input for 5.7.
The fix was to null these out.
-- Convert NULL geometries to actual NULL's
UPDATE myTable SET myGeo = NULL WHERE asText(myGeo) IS NULL;
Related
i try to build an function which returns a json.
I updated my mysql Workbench to 8.0.14 and tried the following code:
SELECT JSON_OBJECT(
'name_field', name_field,
'address_field', address_field,
'contact_age', contact_age
)
FROM contact;
But the following error appears:
Error Code: 1305. FUNCTION datalog.json_object does not exist
I thought that json_object is a standard mysql function, ins't it?
See here:
JSON Object
You're using MariaDB, not MySQL, and your version (MariaDB 10.1) is roughly comparable to MySQL 5.7, with some important differences. Your Workbench version is irrelevant - it's the server version that matters.
https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/
MariaDB 10.1 and above does not support MySQL 5.7's packed JSON objects. MariaDB follows the SQL standard and stores the JSON as a normal TEXT/BLOB. If you want to replicate JSON columns from MySQL to MariaDB, you should store JSON objects in MySQL in a TEXT column or use statement based replication. If you are using JSON columns and want to upgrade to MariaDB, you can either convert the JSON columns to TEXT or use mysqldump to copy these tables to MariaDB. In MySQL, JSON is compared according to json values. In MariaDB JSON strings are normal strings and compared as strings.
MariaDB 10.2.3 adds JSON_OBJECT support. https://mariadb.com/kb/en/library/json_object/
I have mysql 5.6.27 installed on my two servers.
Database has a table which has a column type bigint(20) unsigned NOT NULL.
While inserting a string type value (like 1_2_3_4) in this column on one server it storing value 1 and showing a data truncation warning.
But if i am executing the same query on another server it showing the error message for data truncation and not letting the value inserted.
Just trying to understand why mysql is casting the value on one server but not on another.
Sounds like a configuration issue, specifically strict settings, see https://www.davidpashley.com/2009/02/15/silently-truncated/
I'm trying to create a simple AWS Glue script that would load the data from one MySQL database to another.
I'm stuck at the beginning, because my source DB is configured to use "0000-00-00 00:00:00" as default values for timestamp columns.
I've tried using resolveChoice to convert the column to string, I've also tried (for a test) to only select columns that are not timestamp, but I always get the same error:
java.sql.SQLException: Value '0000-00-00' can not be represented as java.sql.Timestamp
I can't modify the DB to replace those values with NULLs and at this point I can't modify any part of Glue preferences (to include zeroDateTimeBehaviour in the jdbc string)
Upgrading to MySQL5.7 or later will solve this issue.
Changes in MySQL 5.7
I have a table with DATE column. All the dates are valid i.e. no 0000-00-00. But we were in fact using only the year part of these dates. I tried changing the type of this column to YEAR(4), I found following scenarios:
On my local system, MySQL version 5.5.37 via MySQL CLI, changing type retains the year.
On my local system, MySQL version 5.5.37 via Adminer, changing type retains the year.
Our internal DB server, MySQL version 5.0.46 via MySQL CLI, changing type retains the year.
Our internal DB server, MySQL version 5.0.46 via PhpMyAdmin, changing type retains the year.
Staging DB server, MySQL version 5.6.13 via PhpMyAdmin, dates in columns get converted to 0000.
Staging DB server, MySQL version 5.6.13 via MySQL CLI, dates in columns get converted to 0000.
What could cause these issues and how can I solve this? Currently we created a Rake task where we first create an additional column, copy existing column dates to new one, alter the column and copy just years back.
Edit: http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html
Try this
ALTER TABLE `tablename`
CHANGE `columnName` `columnName` YEAR
This returns you 0000 in phpmyadmin. You should create a new column and rename it and then delete the old one.
The YEAR(2) data type has certain issues that you should consider before choosing to use it.
As of MySQL 5.6.6, YEAR(2) is deprecated.
YEAR(2) columns in existing tables are treated as before, but YEAR(2) in new or altered tables are converted to YEAR(4).
Read more here:
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-13.html
When trying to migrate my data from MS SQL to mySQL, essentially converting one database to another I get the following error:
[WRN][copytable]: Invalid timestamp literal detected;"
I've attached a screenshot of what I am getting when using WorkBench. Why would this be occuring? Size of database is 10438MB
configured at my local system with SQL SERVER 2008 R2. I had tried many
freeware utilities for this purposes but failed to do so. Last time i
tried using MySQL workbench to convert this database but again failed. I
tried selection based table conversion as well as the complete database.
Quote:
Datetime - In MYSQL datetime does not contain milliseconds. The SQL
Server datetime datatype contains milliseconds. Error: “Invalid
timestamp literal detected” error. Solution: Convert the datetime
type to a smalldatetime in SQL Server if you do not mind losing the
milliseconds.
from here.