301–310 of 336 posts
Earlier quoted context omitted.
Don't forget IBM
I have managed to find myself accidentally twice at the receiving end of IBM "services". Conclusion was pretty much same both times: Never. F###ing. Again.
Earlier quoted context omitted.
I find the comments in this article very accurate: https://news.ycombinator.com/item?id=15160149 > ORA is the elephant's graveyard of software. > Once something gets bought by them, you know it is done. Slowly, but surely. > They perform a function akin to the maggots that destroy cadavers in nature. Part of the overall ecosystem. > ORA stopped being a tech co a while ago, now it is a finance play. Use cash to buy a…
Just curious, so which companies do people consider are creating/selling interesting and innovative ENTERPRISE software?
Earlier quoted context omitted.
There have been several minor releases in the past 3 years: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/
In semantic versioning parlance those would all be considered "patch" releases, not a "minor" release. The minor version segment in a semantic version is the 2nd number, so most people would consider the next "minor release" for MySQL to be 8.1.0. If following the guidance set out at https://semver.org , a patch release wouldn't add any new functionality, it would just address bugs in a backwards compatible way. A mi…
Earlier quoted context omitted.
If you use any of the really amazing JSON or Array stuff, you're stepping outside of the standard.. but it's worth it!
I absolutely love Postgres' JSON and array support. Its saved me from needing a document database in a few cases, which drastically simplified the overall deployment (one DB instead of two, or trying to represent relational stuff in a document DB). I really like JSON for stuff that is user defined, that I don't need to query into, but postgres' support means I still can should I ever need to. Which has happened once…
And since postgres supports indices on arbitrary expressions you can use CREATE INDEX for the json-queries in your WHERE:
CREATE INDEX ON publishers((info->>'name'));
Perhaps it's due to me being in the PostgreSQL camp, but what happened to MariaDB? I was convinced that's where MySQL developers went and that's where development proceeded, while MySQL was just half dead, because Oracle did not care about it.
MariaDB is massive now. mysql and MariaDB diverged from versions 5.6 and 10 respectively, although MariaDB can and does still merge some fixes from mysql; oracle don’t do that. MariaDB and the original InnoDB developers are now doing heavy rewrites with big performance gains, replication options like multi-source, spider for sharding and galera are all built in and actively maintained. Oracle attempted to extort anyo…
MySQL 5.7 supports multi-source replication: https://dev.mysql.com/doc/refman/5.7/en/replication-channels...
> spider for sharding and galera are all built in and actively maintained.
Galera is available in MySQL-compatible binaries from Percona (Percona-XtraDB-Cluster): https://www.percona.com/software/mysql-database/percona-xtra...
MySQL also has their own Paxos-compliant clustering solution (called "Innodb cluster"), first available in 5.7, but much better in 8.0:
https://dev.mysql.com/doc/refman/5.7/en/mysql-innodb-cluster...
I played with Spider in MariaDB 10.3, and it didn't satisfy the requirements we had, and it doesn't seem to have progressed significantly since then.
Yes, it's neat that MariaDB merged it and is keeping it working, but there don't seem to be many use cases where it ends up being significantly better than e.g. multi-source replication (the use cases where you're going to run out of disk, in most cases spider's un-implemented push-down join etc. make it too slow to be practical either).
> Online schema changes,
https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-op...
(including "instant column add")
> easy horizontal scale (huge numbers that make db2 and oracle sweat), s3 backed tables, non blocking backups,
MySQL has had "MySQL Enterprise Backup" for a long time. Percona wrote a similar implementation (XtraBackup), which works for MySQL, Percona, and MariaDB. AFAIK MariaDB copied XtraBackup as mariabackup (not criticising them for doing this, just pointing out that Percona did the original heavy lifting on this).
> flashback, versioned tables
Yep, versioned tables are a nice feature that I don't think are available in any other MySQL-like DB.
> If you go enterprise, there isn’t much out there as accessible as maxscale for transaction failover!
Not even ProxySQL ( https://proxysql.com/ )?
To be clear, I like MariaDB, but Oracle isn't doing a bad job on MySQL. MySQL 5.7 is pretty solid, and they have been improving defaults (while leaving the option to enable compat settings which are necessary when migrating a large deployment between versions), and MySQL 8.0 has some really nice improvements. For some of the best features from each, Percona (either standard Percona 8.0, which gives features like MariaDB's thread-pool, more comprehensive encryption including redo-logs etc., or XtraDB-Cluster to go with Galera instead of Innodb Cluster) offers quite a few benefits/improvements (and is contributing a lot of bugfixes/improvements upstream).
(My team runs quite a big installation, currently running Percona 5.7, and migrating to MariaDB probably won't be practical or justifiable considering replication compatibility which is a requirement to do no-downtime migrations)
Earlier quoted context omitted.
No, since MySQL 8 doesn't ever claim to use SemVer. They have an explicitly stated policy of including features in point releases. Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? SemVer is an arbitrary versioning scheme, not a universal standard. It's the operator's responsibility to understand the versioning scheme prior to upgrading.
I’m not saying semver is a universal standard but this is _wildly_ different to everything else. Nobody expects defaults to change between patch/minor versions. This is another example of how MySQL does not give a flying F about the footguns it leaves lying around. Putting the onus on the user is not reasonable; especially in a world where we’re trying to reduce toil or get rid of ops completely.
Can you provide an example of an application-side (IOW, not a DB-infrastructure-type variable) that has changed it's default in a patch version after GA in 5.7 or 8.0?
IIRC, all of the defaults changed in very early non-GA versions.
Earlier quoted context omitted.
No. MySQL 8 changed its engineering approach with features released in minor releases. In this regard it is like MacOS X or Windows 10, whatever you prefer where features are shipped without major version change
Sure, and this is great. But The newest release is 8.0.26, so there hasn‘t been any minor release yet - in 3 years. And i can‘t find anything about new MySQL features or planned features except the big 8.0 release.
The average seems to be about 2.5 years between minor releases, so this doesn't seem unusual.
Usually new minor versions are only released if there are: * Changes to database behaviour defaults (e.g. default sql mode) * Deprecation or removal of features * Compatibility changes (changes to replication formats)
New features are fine, as long as they don't introduce regressions in other areas.
Even MySQL 5.7 received some good improvements in the past 18-24 months (not just bug fixes).
I feel this is a really pedantic complaint from someone who either doesn't use MySQL, or wants to hate it for a silly reason.
Earlier quoted context omitted.
No, since MySQL 8 doesn't ever claim to use SemVer. They have an explicitly stated policy of including features in point releases. Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? SemVer is an arbitrary versioning scheme, not a universal standard. It's the operator's responsibility to understand the versioning scheme prior to upgrading.
> Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? Is there another level of patches below point releases for backported security patches, or are your options to upgrade to something that adds new features and may be backwards incompatible, leave your system vulnerable to known security wholes, or patch it yourself (or maybe depend on your distro to do itl
No, because its unecessary (in my experience)
> or are your options to upgrade to something that adds new features and may be backwards incompatible
It won't be backwards incompatible, otherwise they would leave the change for a new minor release.
Why would you not want a new feature (e.g. the new "clone plugin") if it gives you value now without any migration required (because of incompatibilities that may arise if all new features are left for minor versions which are reserved for incompatibilities)?
Earlier quoted context omitted.
I'm also a government Oracle dev. I have no way of knowing what I'm licensed for and they don't disable the features we're not licensed for. I literally have to talk to my director to talk to our account rep to figure out that I'm not allowed to use table partitioning.
Agreed that Oracle licensing is byzantine, probably deliberately. But devil's advocate says that any organization should be aware of what they are actually licensed for, even if that means contracting a third party to ensure compliance.
The whole process was shitty, predatory, and abusive.
Earlier quoted context omitted.
> Why would it be "pretty scary" that a non-SemVer software doesn't use SemVer? Is there another level of patches below point releases for backported security patches, or are your options to upgrade to something that adds new features and may be backwards incompatible, leave your system vulnerable to known security wholes, or patch it yourself (or maybe depend on your distro to do itl
> Is there another level of patches below point releases for backported security patches No, because its unecessary (in my experience) > or are your options to upgrade to something that adds new features and may be backwards incompatible It won't be backwards incompatible, otherwise they would leave the change for a new minor release. Why would you not want a new feature (e.g. the new "clone plugin") if it gives you…
Assuming that is true, this sounds like a normalcy bias to me (https://en.wikipedia.org/wiki/Normalcy_bias).
> Why would you not want a new feature (e.g. the new "clone plugin")
Because features can introduce bugs or performance regressions. Sure you can say that's rare, but I still might not want to take that risk with some of the most critical infrastructure in my app.