Live data from Hacker News

MySQL 8.0 is now generally available

mysqlserverteam.com

51–60 of 105 posts

Re: MySQL 8.0 is now generally available

#51
post #5

Woohoo I've been eagerly awaiting this. I use redshift postgres and SQL server at work and looking to migrate from postgres to MySQL for my personal ML projects. Window functions have been a long time coming and I personally can't wait!

There are a lot of postgres fans on HN, would you mind giving some more info on why you want to go from PG to MySQL?

I did a project with postgres and symfony+doctrine.

At 80% of completion, I moved to mySql because I needed spatial index, I installed Postgis but got a lot of problems with doctrine-migration.

Re: MySQL 8.0 is now generally available

#52
post #13

Earlier quoted context omitted.

In what way is 5.8.0 "ossified"? I swear you're just making up terms now :P ... verb past tense: ossified; past participle: ossified 1. turn into bone or bony tissue. "these tracheal cartilages may ossify" synonyms: turn into bone, become bony, calcify, harden, solidify, rigidify, petrify "the cartilage may ossify" 2. cease developing; be stagnant or rigid. "ossified political institutions" synonyms: become inflexibl…

The same thing happened with Java. After Java 1.4 they just dropped the 1 and released Java 5.

It was a bit weirder with Java, because Java 1.2 was widely marketed as Java 2. They then gave up on it a bit with 1.3 and 1.4, and then adopted it officially with 5.

Re: MySQL 8.0 is now generally available

#53
I had hoped that the SQL improvements would fix this annoyance, but according to the documentation they did not:

  create table fib ( a integer, b integer );
  insert into fib (a, b) values (1, 0);
  update fib set a=a+b, b=a;
  update fib set a=a+b, b=a;
  update fib set a=a+b, b=a;
  update fib set a=a+b, b=a;
  update fib set a=a+b, b=a;
  select a, b from fib;
The correct result according to the SQL standard is a == 8 and b == 5. In MySQL the result is a == 16 and b == 16. They do document this in the manual, saying UPDATE evaluates the assignments left to write, and note that this deviates from the standard.

MariaDB is the same prior to 10.3.5. Starting with 10.3.5 it defaults to left to write evaluation, but you can set the SIMULTANEOUS_ASSIGNMENT mode flag to make UPDATE evaluate the assignments simultaneously instead of left to right.

I believe that all other common SQL databases (Sqlite, PostgreSQL, Oracle, Microsoft SQL Server) follow the standard.

Re: MySQL 8.0 is now generally available

#54

Earlier quoted context omitted.

The same thing happened with Java. After Java 1.4 they just dropped the 1 and released Java 5.

It was a bit weirder with Java, because Java 1.2 was widely marketed as Java 2. They then gave up on it a bit with 1.3 and 1.4, and then adopted it officially with 5.

Even weirder, 1.2 through 5 were all marketed specifically as Java 2, not just their second digit. So today you could be running Java 2 SE 5 Update 85.

Re: MySQL 8.0 is now generally available

#55
I think it's disappointing that MySQL is developed in private and then only pushed to GitHub when released.

I had noticed that it had not been updated in 3 months:

MySQL in the Cloud Native Interactive Landscape https://landscape.cncf.io/grouping=landscape&landscape=datab...

Diff showing last commit https://github.com/cncf/landscape/commit/65f79c653e0fceac9f3...

Re: MySQL 8.0 is now generally available

#56
post #22

> Reliability: DDL statements have become atomic and crash safe, meta-data is stored in a single, transactional data dictionary. Powered by InnoDB! To clarify, does this mean that DDL is now fully transactional the way it is in postgres?

This would be great if so, but it doesn't look like it: https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html > DDL statements, atomic or otherwise, implicitly end any transaction that is active in the current session, as if you had done a COMMIT before executing the statement. This means that DDL statements cannot be performed within another transaction, within transaction control statements such as START TRANSACT…

This is correct. DDLs are (still) auto committed, but they now cannot fail in an intermediate state. Discussing full transactional DDL should also take into account DDL being Replicated and on Online Schema changes (perhaps more important for Web-scale). Then it starts to become complicated supporting full transactional DDL (at the same time). But transactional DDL is absolutely a desired feature. Geir

Re: MySQL 8.0 is now generally available

#57

Woohoo I've been eagerly awaiting this. I use redshift postgres and SQL server at work and looking to migrate from postgres to MySQL for my personal ML projects. Window functions have been a long time coming and I personally can't wait!

You want to go from Postgres TO MySQL‽ Why do you want to do that?

https://eng.uber.com/mysql-migration/

Re: MySQL 8.0 is now generally available

#58
post #2

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago. Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

I feel the same way. I've been using and tracking both since the mid to late 90s.

I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities.

In the meantime PostgreSQL gets better at the same pace.

Re: MySQL 8.0 is now generally available

#59

Woohoo I've been eagerly awaiting this. I use redshift postgres and SQL server at work and looking to migrate from postgres to MySQL for my personal ML projects. Window functions have been a long time coming and I personally can't wait!

As far as I am aware there is no good reason to not use MariaDB instead of MySQL. The creator of MariaDB, Monty Widenius, was on a episode of the changelog podcast if you want to hear some background as to why.

We switched to MariaDB on freebsd 2 or 3 years ago. We ran into a couple performance-destroying bugs and while the devs acknowledged the issues, they made it clear they wouldn't be fixed any time soon. MySQL has been solid for us though.

Just a personal experience.

Re: MySQL 8.0 is now generally available

#60

Earlier quoted context omitted.

You want to go from Postgres TO MySQL‽ Why do you want to do that?

https://eng.uber.com/mysql-migration/

Uber really just needed a key/value store. MySQL works better when used that way since PostgreSQL has MVCC and can lead to table bloat and compaction issues.

I doubt many others ever encounter this issue since picking the correct data store is step 1.

Post reply on HN