Also, this statement is total BS:
"The risk of moving to MariaDB Server if you aren’t using newer MySQL features may be minimal, but the risk of moving out of MariaDB Server to MySQL is very prevalent."
Here is the correct statement:
"The risk of moving to MariaDB Server if you aren’t using newer MySQL features may be minimal, and the risk of moving to MySQL server if you aren't using newer MariaDB features is also minimal."
I switch between multiple versions of MySQL and MariaDB all day long. If you aren't using specific things like MySQL's JSON type or NDB storage engine or expecting CHECK constraints to enforce on MySQL (oddly omitted from this feature comparison!), there is nothing different at all from a developer point of view, beyond the default values of flags which honestly change more between MySQL releases than anything else.
As the maintainer of SQLAlchemy I think MySQL more often makes backwards-incompatible changes more often than MariaDB, such as just from 5.7.19 to 5.7.20 they decided to change the name of "@tx_isolation" to "@transaction_isolation" (and no, "@transaction_isolation" is not in 5.7.19, they just changed the name on a point release) and start emitting a prominent, scary warning when you use @tx_isolation that is breaking people's CI builds - on a point release.
The reason a vendor like Percona or a linux distro chooses to favor MySQL or MariaDB is mostly about that vendor's relationship with Oracle (or lack thereof) more than anything else. I'm stuck using both all the time but the MariaDB community certainly feels more accessible than trying to get through to people working at Oracle.
Close. Percona is a consulting firm specializing in MySQL (expanding to other things). Percona's race horse is MySQL the actual company and actual maintainers. They view MariaDB as a type of competition against their friends at MySQL. Good luck spotting the differences between Maria vs Mysql. I have gathered that from the many SFMysql meetups I have attended. The Mysql guys would show off their newest feature that beats MariaDB.
Percona is amazing and without the pt-online-schema-change tool, I would probably be a bar tender. If you ever get in a bad database bind they are worth every penny.
Without the pt-online-schema-change, you would likely use gh-ost :-)
In MySQL 8.0, it is called transaction_isolation which is the name used by configuration files. MySQL 5.7 supports both names, but now warns when using the old name.
Supporting old+new names is required to support distributed apps which may upgrade a shard at a time (i.e. you want your code to work on both MySQL 5.7 and 8.0). But there is a deprecation warning to let you know which version is preferred.
Calling it an incompatible change is perhaps a little strong. The idea behind the deprecation warning is to give you as much notice as possible.
Definitions of backwards incompatibility are either tautological or disingenuous (provided we talk about documented behavior).
The right way to do that change would have been to allow both names without warnings in a point/minor release (with the docs stating where the project is headed), add the depreciation warning with the next semver major one, and remove the old name on the next next semver major release.
Unfortunately, "database suddenly emits a prominent, unconditional warning upon upgrade to 5.7.20" is a breaking change in many situations.
I'm assuming you know pretty much every dark corner of the dbs you have engines for in sqla. It must be a little hard forever supporting strange breakages like your example above when it's a db you don't care for as much.
I'm personally a little annoyed at PG's efforts to turn SQL into half an OO programming language (see http://ledgersmbdev.blogspot.com/2012/08/postgresql-or-model... for examples), but for selfish reasons; features like these are meant as replacements for what you get from a tool like SQLAlchemy Core and the unusual syntaxes they have are also really hard to implement yet I continually get asked to implement more of them. These aren't reasons I wouldn't use Postgresql it's just this little cloud of "ugh" that hangs over me when I really have to dig into PG :).
It also makes me cringe a bit the way Postgresql spawns a child process on the server for every database connection still. MySQL has very cheap connections and that's still a pretty compelling reason to keep it in mind for some kinds of applications (applications called Openstack which eat up thousands of connections...).
In the closed source world, MS SQL Server has really been getting a lot easier to use and I'm very impressed at their linux version, I have it running in docker and it is 100% exactly the same as the windows version as far as SQL / client interaction. None of this "MySQL default casing conventions are OS-dependent" stuff (see https://dev.mysql.com/doc/refman/5.7/en/identifier-case-sens... , and prepare to be amazed what hacky cruft still lives on within the MySQL ecosystem).
I read that link and didn't get it - has anyone a fuller explanation or other links to recommend?
select * from inventory_item i where (i.cogs_account).control_code = '5500';
It doesn't seem like a great idea to me. You can't really tell what's happening and there's a huge performance impact in doing it. The query planner is going to be a bit limited in what it can do.
The example following where you have a save procedure against a column is a bit baffling.
FROM (SELECT (row(null, 3, 1, 2, 'TEST124',
'Inventory testing item 2', 1, 2,
Think I'll stick to SQLA on that front thanks!
Mike, maybe I misundertood this, but I think they meant actually moving /var/lib/mysql between maria/mysql.
(This is only be true if you're using GTIDs in MariaDB, the old file:position format is still compatible. MariaDB does understand MySQL GTIDs, so replication from MySQL to MariaDB does work when using GTIDs in MySQL.)
It could be pretty difficult to get and install mysql. I recall times where you needed to go to the Oracle website and check some EULA manually before you could get a temporary download link. Quite a stand against automation.