i have been working with the JSON COLUMN_CREATE and COLUMN_JSON options in mariaDB. how do i update just one JSON column without having to extract the entire JSON column?
i see that mysql now has a JSON_SET option. is this something that mariaDB will add?
when i first switched over from mysql to mariaDB the documentation seemed to elude to mariaDB being a "drop-in" replacement for mysql.
also, i thought i read initially that if mysql comes out with a new feature, mariaDB will match the feature.
"drop-in replacement" = "marketing". However, it is mostly true.
You have ventured into a very new feature (JSON) of Oracle MySQL, for which MariaDB has not (yet) caught up. I cannot say when (or even 'if') it will catch up in this.
Meanwhile, MariaDB has added a number of features that have not (yet) been adopted by Oracle.
Related
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 have an issue with HSQLDB, I have a MySql database that I'm dumping to an in memory HSQLDB i get the following error when I run the script: Error: unexpected token: ( which is on a create table script and the offending line is TINYINT(3)
if I remove the brackets and the number it works fine, this is a valid declaration on MYSQL and I have tried turning MYSQL compatibility on by changing my url to: jdbc:hsqldb:mem:dataSource;sql.syntax_mys=true but this still doesn't work. :(
just as additional info I'm using a Spring hibernate connection and using Liquibase to do the dumping from MySQL to HSQLDB and I'm running HSQLDB v2.3.2
SQL Syntax especially DDL is not very well portable between different databases. You will have to learn the correct syntax for create table in HSQLDB witch is somewhat different from MySQL.
You can not just export table definition from one flavor of database and import into another.
Would be great if this would be the case but SQL Standard is quite loose...
I assume you have a DDL-Script, you can add SET DATABASE SQL SYNTAX MYS TRUE; to the top of it, see also here (Table 13.29. MySQL Style Syntax).
You may use this only for tests though; if you want to fully migrate to HSQLDB, changing the scripts themselves is sure the long term solution.
Looking at a mySQL Dump, I have come across something and like to know what they are.
I see:
/*!50001 DROP TABLE IF EXISTS `xxx` */;
What is the flag 50001, is there a list of what they mean?
It is discussed on the MySQL's forums/mailing lists here.
/*!50001 DROP TABLE `category_count_view`*/;
This is a "feature" of MySQL. Any other RDBMS will treat this as a
comment.
But, MySQL looks at 50001 and checks that as a MySQL version. This is
Version 5.00.01, or 5.0.1 in the real world, but leaves room for the
the sub-version and release to be greater than 9.
MySQL will treat the line as a comment if MySQL is below 5.0.1, and
will process the line if MySQL is greater than or equal to 5.0.1.
It's a way making a SQL script compatible with different versions of
MySQL, and allows new features to be included.
The 500001 is regarding the MySQL version that generated the file.
This would be 5.00.01 or 5.0.01
50001 is a value that indicate your mysql version.
This is Version 5.00.01, or 5.0.1 in the real world, but leaves room for the the sub-version and release to be greater than 9.
It's a way making a SQL script compatible with different versions of MySQL, and allows new features to be included.
I'm trying to connect to an Informix database with SQLAlchemy. All my tests seem to show the connection is working; however, whenever I try and perform a read of the database I get the error:
DatabaseError: (DatabaseError) SQLCODE -217 in PREPARE:
IX000: Column (current_role) not found in any table in the query (or SLV is undefined).
'select CURRENT_ROLE from systables' ()
Now the database that I am connecting to doesn't have CURRENT_ROLE, so how can I get round this?
My interactive traceback of the error is shown below in a gist:
https://gist.github.com/2157378
The offending line is:
File "build/bdist.linux-i686/egg/sqlalchemy/dialects/informix/base.py", line 593, in _get_default_schema_name
return connection.execute('select CURRENT_ROLE from systables').scalar()
Is there any workaround for this problem?
I am now led to believe this is a bug in SQLAlchemy (after talking to users in #sqlalchemy) and I have filed a bug report:
http://www.sqlalchemy.org/trac/ticket/2448
You've not identified which version of IBM Informix Dynamic Server (IDS) you are using or which platform you are using it on, so it is hard to help you.
It appears that SQLAlchemy expects a more recent version of Informix than you are using. Somewhat to my surprise, the niladic function CURRENT_ROLE appears to be available in IDS 11.70 (tested on 11.70.FC4 on RHEL 5 for x86/64). It was not recently added, so it will be in any 11.70 version, and possibly in some earlier versions (but not as early as the version you are using).
I'm not sure how much of a bug it is in SQLAlchemy. If the version of Informix that you're using is really old, there is limited virtue in them adding support for it. You can find out which version you're using by running:
SELECT DBINFO('version', 'full')
FROM 'informix'.systables
WHERE tabid = 1;
If that doesn't work, you are many years out of date with your server.
Addendum
Thinking about it a bit more...I wonder what SQLAlchemy is going to do with the role. It probably shouldn't be trying to analyze whether you have permission; it should try an operation and deal with failures. That will be quicker, especially in the common case where you actually do have permission.
There could be two issues:
SQLAlchemy should be aware that some (as yet indeterminate) list of old versions of IDS do not support CURRENT_ROLE.
SQLAlchemy should review why it needs to be aware of the current role.
Recently i am working on a replication between heterogeneous dbs with Tungsten Replicator. We have a mysql master and an oracle slave. According to the docs such a setup should work. I am using tungsten-replicator-2.0.5. I call
$TUNGSTEN_HOME/tools/configure \
--verbose \
--home-directory=$INSTALL_HOME \
--cluster-hosts=$MA_HOST,$SL_HOST \
on the master node for creating a basic installation on both nodes. Note: using the installer (as recommended) fails, due to the heterogeneous setup, since the installer fails to find a mysql instance on the slave node. The replicator instances are configured by adding static-$SERVICENAME.properties to the conf directory and modifying conf/services.properties (replicator.host=$HOSTNAME, replicator.masterListenPortStart=12112, replicator.rmi_port=20000).
Launching the replicators resulted in an ORA-01850 when issuing an update statement against trep_commit_seqno in the tungsten schema, due to a missing 'timestamp' keyword in the SQL-Statement. Just in order to get beyond this error, i altered datatype of update_timestamp and extract_timestamp to varchar. The replicators are now starting up und some simple inserts where replicated but when the test script issues a
DROP TABLE IF EXISTS table1;
replication fails due to an ORA-00933, because of the 'IF EXISTS' clause. I am not sure if this is an error in my configuration or if tungsten in general has problems with the differences in DDL statements between those two products. Has somebody successfully set up a similar replication using tungsten?
The Tungsten docuemntation has some useful guidance. In particular, this point from the "Advanced Principles of Operation" is relevant: "Also, DDL statements beyond the simplest CREATE TABLE expressions are rarely at all portable. ". In your case, DROP TABLE IF EXISTS table1; is not valid Oracle DDL.
Read it here.
For anybody who is interested: Up to now, Tungsten does not perform any transformation of ddl statements in a heterogeneous environment (as MithunSasidharan wrote). Now i wrote a custom filter, that skips ddl statements using regular expressions. For synchronizing the schema defition, we will use Apache DdlUtils, which serves quite well for transforming a schema definition between mysql and oracle. I assume it works for other vendors similarly well. Thanks.