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/
Related
I tried to add a json column to my database by using phpMyAdmin
but Unfortunately, phpMyAdmin converts the json column to Longtext type
So, I'm asking about the ability to use the JSON Where Clauses with this type
https://laravel.com/docs/5.7/queries#json-where-clauses
You cannot use those queries on non-JSON data types in MariaDB. And as of 10.2, it doesn't officially support it.
You can use the JSON helper functions to query against data (ie: where JSON_CONTAINS(...) and others.
You can also create columns that are extracted values from the JSON data using Virtual Columns
Here's a good post with much more detail.
I'm trying to add a column of type JSON to one of my tables. I'm using XAMPP with phpmyadmin. The server version is 10.1.31-MariaDB. The innodb version is 5.6.36-83.0
When i try to select the JSON type from the select-box in phpmyadmin, i do not see anything about JSON. Also, running this query results in a "syntax error":
ALTER TABLE my_table
ADD `some_column` json;
I've seen both in the manual, and in various tutorials, that mysql indeed does support JSON type.
Is it a version issue? To be honest, i'm very confused about the whole mysql versioning situation. I see on Wikipedia, that the latest stable release is 8.0.11, whereas mine seems to be something completely different(i dont know which is relevant: the "server" or the "innodb" version) I would assume that XAMPP uses the latest mysql version, but maybe i'm wrong.
Can someone shed some light on the issue? If it is actually a version thing, would it be possible to upgrade, while still using XAMPP?
It seems that this data type is only available from MariaDB version 10.2.7. You can use LONGTEXT instead, because according to the docs JSON is only an alias for LONGTEXT.
https://mariadb.com/kb/en/library/json-data-type/
Yes, it's a version issue, see https://mariadb.com/kb/en/library/mariadb-vs-mysql-compatibility/
You're using MariaDB 10.1, which is based on MySQL 5.6/5.7 (hence the innodb version). But the JSON data type was added in MySQL 8.0. It looks like as of this time MariaDB doesn't support the JSON data type.
The JSON data type as added in version 5.7 and is improved in 8. MariaDB does not have a JSON data type
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;
I have a string stored as json in a mysql table. I need to parse the string and return the value within a stored procedure.
Does Mysql 5.5 support this?
I came across this UDF: https://github.com/ChrisCinelli/mysql_json
Unfortunately, I cannot install this UDF on my mysql server due to operational issues.
How to parse json in mysql?
Note: We use percona version of MySQL
I ended up using common_schema: https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/common-schema/common_schema-2.2.sql
It has json parsing function: https://common-schema.googlecode.com/svn/trunk/common_schema/doc/html/extract_json_value.html
I'm debugging an old application in Delphi 5, connected with a recent version of MySql via ODBC connector. When using a CAST conversion function, even the following query:
select cast(1 as char)
returns an empty column without column name.
If I run the query directly into the mysql query analyzer it runs fine, so I suppose the problem is in the ODBC connector or in BDE.
The only information I can find on this is this (emphasis mine):
Connector/ODBC erroneously reported that it supported the CAST() and CONVERT() ODBC
functions for parsing values in SQL statements, which could lead to bad SQL generation
during a query.
Could it be that the connector does not support CAST at all?
Try creating a stored procedure in the database to perform the CAST and hide it from ODBC.