Xeround MySQL limitation conflicts?
Hi all,
We're considering implementing VF with Xeround. Xeround supports the MySQL command set, but it has some limitations (see below). Should we be worried about any of these for a standard VF install?
- Phil
The following SQL functionality is NOT SUPPORTED in the current release:
ALTER TABLE {ADD|DROP} PRIMARY KEY. A table’s primary key constraint can only be defined while creating a table and as a part of the CREATE TABLE DDL.
ALTER TABLE for column type change
INSERT IGNORE, INSERT …ON DUPLICATE KEY UPDATE & REPLACE – these statements are supported for a single operation transaction, or when the duplicate values are both in the same transaction. In bulk operations/transactions, a uniqueness constraint violation might fail the entire transaction.
Log files
Event
Save points
The following Grant options : MAX_QUERIES_PER_HOUR, MAX_UPDATES_PER_HOUR, MAX_CONNECTIONS_PER_HOUR and MAX_USER_CONNECTIONS
Spatial extensions: data types, indexes and functions
The following indexes-related functionality:
RTREE
FULL TEXT index types
Show index collation & cardinality
LOCK statements
In addition, the following limitations apply:Hash index has a limited cardinality of 1000 per value – for higher cardinality please use Btree index
Maximal transaction size should not exceed 100M
Due to schema distribution process among the various nodes, it is highly recommended to wait at least 30 seconds after performing DDL operations before referring to its results
Foreign Key constraints are supported but not enforced
Host based privileges are not enforced – it is highly recommended that you do not use them as these may result in unexpected behavior
SSL connections are not supported
AUTO_INCREMENT columns support only positive integer values
Cascading triggers are supported but are not included in the scope of the original transaction
LOAD DATA INFILE statements are supported only when executed with the LOCAL keyword
Please also be aware of the following topics:Xeround uses Optimistic Concurrency Control in implementing ACID transactions. Therefore applications should deal with failures when committing changes
When using table scan operations, the order of the returned data is not guaranteed. To assure the order of the returned data, please use the ORDER BY clause
INSERT INTO MYTABLE (PK) SELECT MYTABLE.PK + 5 FROM MYTABLE WHERE PK > 100;) may result in unexpected behavior as some rows might be inserted more than once
INSERT INTO…ON DUPLICATE KEY UPDATE – AUTO_INCREMENT on the primary key will increment even if INSERT finds a duplicate key and an UPDATE was executed.
(source: http://xeround.com/developers/release-notes/ )
Best Answers
-
x00 MVP
it is not a good fit. The structure builder itself figures out if it need to alter or create, I know I have created plugin that wouldn't work with their limitations. It work on a standard implementation of mysql.
I think stuff like this is best used with something built form the ground up to use it, or it has to mature further, so it is analogous to mysql.
The team have said and I agree, that their future interest is not to support sql variants. If they are going to make a shift it will be in the no-sql direction. That would work better as a cloud database.
grep is your friend.
0 -
Todd Vanilla Staff
In general, if you don't have the ability to fix issues that may come up around your xeround implementation then I wouldn't go there. We don't have the ability to come in and troubleshoot for you so you'd kind of be stuck.
0
Answers
it is not a good fit. The structure builder itself figures out if it need to alter or create, I know I have created plugin that wouldn't work with their limitations. It work on a standard implementation of mysql.
I think stuff like this is best used with something built form the ground up to use it, or it has to mature further, so it is analogous to mysql.
The team have said and I agree, that their future interest is not to support sql variants. If they are going to make a shift it will be in the no-sql direction. That would work better as a cloud database.
grep is your friend.
In general, if you don't have the ability to fix issues that may come up around your xeround implementation then I wouldn't go there. We don't have the ability to come in and troubleshoot for you so you'd kind of be stuck.