Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MySQL 8.0 is now generally available

mysqlserverteam.com

Post reply on HN
Print view View original

21–30 of 105 posts

Re: MySQL 8.0 is now generally available

#21

Post by mathnode »

johannes1234321 wrote: post #12
crazygringo wrote: post #8

Side question, but why the jump from 5.7 to 8.0? What happened to 6.0 and 7.0? Edit: found a kind of answer, though I never heard of 6 and 7 being "used" before. [1] > Why did MySQL version numbering skip versions 6 and 7 and go straight to 8.0? > Due to the many new and important features we were introducing in this MySQL version, we decided to start a fresh new series. As the series numbers 6 and 7 had actually bee…

MySQL 6 was used some 10+ years ago and has seen some alphas. Over time most things in there have been backported into the 5 series and some ideas for 6.0 didn't work out (i.e. Falcon storage engine) and were stopped. When/how 7 was used I'm not sure, but jumping from 5.7 to 8 simply drops the first digit, which was meaningless for a while already. (jumps from 5.5 to 5.6 and 5.6 to 5.7 were huge as well)

I have fond memories of playing with 6.0 Alpha and the Falcon engine.

And my favourite feature, the "BACKUP" command. Shame.

Re: MySQL 8.0 is now generally available

#22

Post by theptip »

semiquaver wrote: post #4

> 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 TRANSACTION ... COMMIT, or combined with other statements within the same transaction.

Sounds like it just means that single ALTER/ADD/REMOVE statements now cannot fail in an intermediate state, but a sequence cannot be run in a transaction, so there's still a manual process to unpick a migration that failed half-way through. (That's always fun in production...)

Perhaps the groundwork has been laid though, and it'll be possible in 9.0.

Re: MySQL 8.0 is now generally available

#24

Post by genieyclo »

giancarlostoro wrote: post #9
crazygringo wrote: post #8

Side question, but why the jump from 5.7 to 8.0? What happened to 6.0 and 7.0? Edit: found a kind of answer, though I never heard of 6 and 7 being "used" before. [1] > Why did MySQL version numbering skip versions 6 and 7 and go straight to 8.0? > Due to the many new and important features we were introducing in this MySQL version, we decided to start a fresh new series. As the series numbers 6 and 7 had actually bee…

People are going to start to think tech companies don't know how to count or something. Jokes aside... I'm wondering the same.

Oracle 18...

Re: MySQL 8.0 is now generally available

#25

Post by madenine »

superice wrote: post #15
orf wrote: post #5

Earlier quoted context omitted.

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?

There are some nice features that MySQL lacks. Personally, the thing I like best in Postgres is transactional DDL. In MySQL, if halfway through a database transformation your migration script fails, you are in a broken state and you are on your own. Postgres rolls the whole transaction back. Ofcourse there are some other features MySQL lacks, such as variable length character columns (varchar) where you don't need to…

The advantages of Postgres (and MariaDB) over MySQL are pretty well traveled on HN. OP wants to move from Redshift Postgres & SQL Server to MySQL - which isn't something you see very often.

Re: MySQL 8.0 is now generally available

#26

Post by Something1234 »

purerandomness wrote: post #17
go_prodev wrote: post #3

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!

Redshift is forked off an ancient Postgres version, consider using a more recent (10 or 11 beta) real Postgres version.

Like AWS redshift the nosql database or what? What is redshift postgres?

Re: MySQL 8.0 is now generally available

#27

Post by morgo »

meritt wrote: post #7
dancek wrote: 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.

The big features that MySQL has been lacking, MariaDB has had since at least 10.2 (Apr 2016) or earlier. Specifically I'm talking about Windowing functions, CTEs, JSON support, GIS support, Metadata in transactions (DDL statements). At this point MySQL is playing catch-up to MariaDB.

Former MySQL Product Manager here (no longer affiliated). To cover your specifics:

MySQL was first in offering JSON with 5.7. It is still well ahead, for example, there is no JSON_TABLE, aggregate functions, native type or partial update in MariaDB. Some examples of the value here: https://mysqlserverteam.com/mysql-8-0-from-sql-tables-to-jso...

Both have always had GIS support, but have taken it in a different direction. With MySQL, the GIS is now based on Boost.Geometry and has Geography support.

w.r.t. metadata in transactions - I am not sure which feature you refer to here. The native innodb-based dictionary is a MySQL only feature.

For Window functions and CTEs, they were added at a similar time, but MySQL is on a ~3yr release cycle. MariaDB is on a ~1yr.

Re: MySQL 8.0 is now generally available

#28

Post by da_chicken »

tenken wrote: post #13
yrro wrote: post #10

Earlier quoted context omitted.

The usual radix promotion that tends to occur when the major version becomes ossified. 5.8.0 -> 8.0

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.

Re: MySQL 8.0 is now generally available

#30

Post by reilly3000 »

Something1234 wrote: post #26
purerandomness wrote: post #17

Earlier quoted context omitted.

Redshift is forked off an ancient Postgres version, consider using a more recent (10 or 11 beta) real Postgres version.

Like AWS redshift the nosql database or what? What is redshift postgres?

AWS Redshift is their data warehouse database. It uses Postgres syntax. DynamoDB is their NoSQL offering.
Post reply on HN