I use the freshest MariaDB:
select ##version
10.4.8-MariaDB
When run this cript:
CREATE TABLE t1 (
uuid_field VARCHAR(32) DEFAULT (uuid()),
binary_uuid BINARY(16) DEFAULT (UUID_TO_BIN(UUID()))
);
receive the error:
Function or expression 'UUID_TO_BIN()' cannot be used in the DEFAULT clause of binary_uuid
For the test I run this and it works:
CREATE TABLE t2 (
uuid_field VARCHAR(32) DEFAULT (uuid()),
binary_uuid BINARY(16)
);
What is the problem in the 1st case? Is it possible to use user's functions in the DEFAULT clause?
DEFAULT Column Option¶
MariaDB starting with 10.2.1
The DEFAULT clause was enhanced in MariaDB 10.2.1. Some enhancements include
The DEFAULT clause can now be used with an expression or function.
It means: built-in functions only, but not user-defined
Make binary_uuid a "Generated column" instead.
Related
I've got a problem while creating (altering) foreign key.
I have two tables in my DB (created via flyway migrations):
connector (migration)
create table if not exists connector
(
id char(36) not null,
# other fields omitted
primary key (id)
) DEFAULT CHARACTER SET 'utf8mb4'
COLLATE 'utf8mb4_unicode_520_ci';
connector_preset (migration)
CREATE TABLE IF NOT EXISTS connector_preset
(
id CHAR(36) NOT NULL,
# other fields omitted
PRIMARY KEY (id)
);
I want to create a link between connector and connector_preset, so I created another migration like this:
ALTER IGNORE TABLE `connector`
# `connector_preset`.`id`
ADD COLUMN IF NOT EXISTS `preset_id` CHAR(36),
ADD CONSTRAINT `fk_connector_preset_id` FOREIGN KEY (`preset_id`) REFERENCES `connector_preset` (`id`);
but it fails with the following error:
SQL State : HY000
Error Code : 1005
Message : (conn=4) Can't create table `test`.`connector` (errno: 150 "Foreign key constraint is incorrectly formed")
Location : db/migration/...
Line : 34
Statement : ALTER IGNORE TABLE `connector`
# `connector_preset`.`id`
ADD COLUMN IF NOT EXISTS `preset_id` CHAR(36),
ADD CONSTRAINT `fk_connector_preset_id` FOREIGN KEY (`preset_id`) REFERENCES `connector_preset` (`id`),
The columns seem to be of the same type. Also, for some reason it works in local k8s cluster (10.3.29-MariaDB), but fails in integration tests (testcontainers, MariaDB 10.6.11). Also fails in GH Actions which use 10.3.29, which is strange since it's working locally.
UPD: If I set mariadb version in testcontainers to 10.3.29 - it still fails.
UPD: Tried altering connector_preset table to use the same charset and collation:
ALTER IGNORE TABLE `connector_preset` DEFAULT CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_unicode_520_ci';
Still doesn't work
Table connector was created with character set utf8mb4 and collation utf8mb4_unicode_520_ci, while connector_preset was created with servers default character set and collation, which obviously differs.
So you have to convert your table to the right character set.
Your attempt to change it with ALTER TABLE ... DEFAULT CHARACTER SET 'utf8mb4' sets the default character set for the table, but not for the columns. Instead you have to convert it with:
ALTER TABLE connector_preset CONVERT TO CHARSET utf8mb4 COLLATE utf8mb4_unicode_520_ci
I have created a table:
CREATE TABLE IF NOT EXISTS `tablename` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Then I run a query via myBatis (as defined in the mapper.xml-file):
SELECT .. FROM `tablename`;
This query fails with
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'databasename.TABLENAME' doesn't exist
How can I force myBatis to query with the specified lowercase name "tablename" instead of doing an uppercase-translation?
I found this: https://mybatis.org/generator/configreference/table.html where it is said, that myBatis gets the info on how to deal with case sensitivity from the database itself.
So I checked with
SHOW VARIABLES;
the settings and got:
lower_case_file_system OFF
lower_case_table_names 0
This means if I understand https://mariadb.com/kb/en/identifier-case-sensitivity/ right, that the database indicates that the tablenames are case sensitive. Why does myBatis then force to given lowercase names to uppercase before issuing the query?
Thanks in advance.
Sorry, completely my fault. Had changed my code and committed - but not pushed. So my changes in the mapping.xml did not become active in deployment.
The query, the way I had described above works.
I am trying to use the Federated engine of MariaDB 10.1.12 to create tables that are based on tables in a remote database. Following the MariaDB instructions about how to use the FederatedX implementation, in database db1 I create a table as
CREATE TABLE test_table (
id int(20) NOT NULL auto_increment,
name varchar(32) NOT NULL default '',
other int(20) NOT NULL default '0',
PRIMARY KEY (id),
KEY name (name),
KEY other_key (other))
DEFAULT CHARSET=latin1;
Now when I want to see this table in a second database db2 using the Federated engine, I can issue
CREATE TABLE test_table (
id int(20) NOT NULL auto_increment,
name varchar(32) NOT NULL default '',
other int(20) NOT NULL default '0',
PRIMARY KEY (id),
KEY name (name),
KEY other_key (other)
) ENGINE=FEDERATED
DEFAULT CHARSET=latin1
CONNECTION='mysql://user_x:pass_y#localhost/db1/test_table';
All this is copied from the MariaDB documentation and works well. However, if I try to create the table without explicitly duplicating the definition of the table structure - an example given in the same documentation
CREATE TABLE test_table ENGINE=FEDERATED DEFAULT CHARSET=latin1
CONNECTION='mysql://user_x:pass_y#localhost/db1/test_table';
MariaDB responds with an error
ERROR 1113 (42000): A table must have at least 1 column
Am I missing something or is it not possible to use federated tables without specifying the individual columns?
It seems that with the standard installation of MariaDB on Ubuntu 14.04, the old Federated engine is active, not the new FederatedX variant. Only the latter supports auto-discovery of columns. In order to correct this, I took the following steps:
uninstall soname 'ha_federated';
to remove the federated plugin. After a server restart, the correct one is loaded with
install plugin federated soname 'ha_federatedx';
This loads the new FederatedX implementation supporting auto-discovery of columns. To view the installed engines, one can list them with
show engines;
If all is correct, there should be this line in the output:
| FEDERATED | YES | FederatedX pluggable storage engine |
update table set column_name limit 3 offset 2;
The above query is not working.
Throws error
sql error: syntax error near 'limit'.
An UPDATE statement expects a new value after the column_name, like this:
update thetable set column_name = 'some new value'
Furthermore, the documentation mentions that you need to have compiled SQLite with the SQLITE_ENABLE_UPDATE_DELETE_LIMIT option, which is not enabled by default.
Sqlite does not allow the use of LIMIT and OFFSET statements like in MYSQL. You will have to use a nested query to workaround it . Or use two queries.
Here's the problem. In MySQL's Connector/NET a TINYINT(1) field properly translates back and forth into a .NET bool value. If I select from a table with a TINYINT(1) column, everything is golden. However, when you use built-in MySQL v5.0 functions like:
SELECT (3 BETWEEN 2 AND 4) AS oddly_not_boolean;
The actual return type from the database registers this field as INT or BIGINT, which Connector/.NET obviously doesn't convert to bool. MySQL CAST() and CONVERT() do not allow casting to TINYINT(1).
I've even gone so far as to try a user function to do this, but this doesn't work either (EDIT: this does work):
CREATE FUNCTION `to_bool`(var_num BIGINT)
RETURNS TINYINT(1) RETURN var_num;
How do I convert an INT to a TINYINT(1) in a query in MySQL?
EDIT: The above function DOES actually work to convert the value to a TINYINT(1), but my Connector/NET is just bugged and doesn't properly convert the values from functions.
UPDATE 2009-11-03: Updated my connector and it's still giving me back Int32. Further testing reveals that this is an InnoDB bug in MySQL 5.0.x that only shows under specific circumstances.