(I am using a DigitalOcean MySQL 8 cluster)
When performing the prisma2 lift save operation, only the _Migrations table and the actual migration is not perform on a MySQL 8 instance.

Stack trace:
LiftEngine:rpc SENDING RPC CALL { id: 1,
jsonrpc: '2.0',
method: 'listMigrations',
params:
{ projectInfo: '',
sourceConfig:
'datasource db {\n provider = "mysql"\n url = "mysql://<redacted>:<redacted>@domain.com:25060/defaultdb?ssl-mode=required"\n}\n\nmodel User {\n id String @id @default(cuid())\n name String\n}' } } +0ms
LiftEngine:rpc SENDING RPC CALL { id: 2,
jsonrpc: '2.0',
method: 'inferMigrationSteps',
params:
{ projectInfo: '',
sourceConfig:
'datasource db {\n provider = "mysql"\n url = "mysql://doadmin:r6ubovtpcidxrk1z@db-mysql-nyc1-25634-do-user-2895345-0.db.ondigitalocean.com:25060/defaultdb?ssl-mode=required"\n}\n\nmodel User {\n id String @id @default(cuid())\n name String\n}',
datamodel:
'datasource db {\n provider = "mysql"\n url = "mysql://doadmin:r6ubovtpcidxrk1z@db-mysql-nyc1-25634-do-user-2895345-0.db.ondigitalocean.com:25060/defaultdb?ssl-mode=required"\n}\n\nmodel User {\n id String @id @default(cuid())\n name String\n}',
migrationId: 'DUMMY_NAME',
assumeToBeApplied: [] } } +4s
LiftEngine:stderr thread 'tokio-runtime-worker-1' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345:21 +0ms
LiftEngine:stderr note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. +165ms
LiftEngine:stderr stack backtrace: +0ms
LiftEngine:stderr 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace +0ms
LiftEngine:stderr 1: std::sys_common::backtrace::_print +0ms
LiftEngine:stderr 2: std::panicking::default_hook::{{closure}} +0ms
LiftEngine:stderr 3: std::panicking::default_hook +0ms
LiftEngine:stderr 4: std::panicking::rust_panic_with_hook +0ms
LiftEngine:stderr 5: std::panicking::continue_panic_fmt +0ms
LiftEngine:stderr 6: rust_begin_unwind +1ms
LiftEngine:stderr 7: core::panicking::panic_fmt +0ms
LiftEngine:stderr 8: core::panicking::panic +0ms
LiftEngine:stderr 9: <&str as prisma_query::connector::result_set::index::ValueIndex<prisma_query::connector::result_set::result_row::ResultRow,prisma_query::ast::values::ParameterizedValue>>::index_into +0ms
LiftEngine:stderr 10: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once +0ms
LiftEngine:stderr 11: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter +0ms
LiftEngine:stderr 12: sql_migration_connector::database_inspector::information_schema::InformationSchema::get_columns +0ms
LiftEngine:stderr 13: sql_migration_connector::database_inspector::mysql_inspector::MysqlInspector::get_table +0ms
LiftEngine:stderr 14: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold +0ms
LiftEngine:stderr 15: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter +0ms
LiftEngine:stderr 16: <sql_migration_connector::database_inspector::mysql_inspector::MysqlInspector as sql_migration_connector::database_inspector::DatabaseInspector>::introspect +0ms
LiftEngine:stderr 17: <sql_migration_connector::sql_database_migration_inferrer::SqlDatabaseMigrationInferrer as migration_connector::database_migration_inferrer::DatabaseMigrationInferrer<sql_migration_connector::sql_migration::SqlMigration>>::infer +0ms
LiftEngine:stderr 18: <migration_core::commands::infer_migration_steps::InferMigrationStepsCommand as migration_core::commands::command::MigrationCommand>::execute +0ms
LiftEngine:stderr 19: <migration_core::api::MigrationApi<C,D> as migration_core::api::GenericApi>::infer_migration_steps +0ms
LiftEngine:stderr 20: migration_core::api::rpc::RpcApi::create_sync_handler +0ms
LiftEngine:stderr 21: tokio_threadpool::blocking::blocking +0ms
LiftEngine:stderr 22: <futures::future::lazy::Lazy<F,R> as futures::future::Future>::poll +0ms
LiftEngine:stderr 23: <futures::future::then::Then<A,B,F> as futures::future::Future>::poll +0ms
LiftEngine:stderr 24: <futures::future::lazy::Lazy<F,R> as futures::future::Future>::poll +1ms
LiftEngine:stderr 25: futures::future::chain::Chain<A,B,C>::poll +0ms
LiftEngine:stderr 26: <futures::future::then::Then<A,B,F> as futures::future::Future>::poll +1ms
LiftEngine:stderr 27: <futures::future::map::Map<A,F> as futures::future::Future>::poll +0ms
LiftEngine:stderr 28: <futures::future::either::Either<A,B> as futures::future::Future>::poll +0ms
LiftEngine:stderr 29: <futures::future::map::Map<A,F> as futures::future::Future>::poll +0ms
LiftEngine:stderr 30: <futures::future::map_err::MapErr<A,F> as futures::future::Future>::poll +0ms
LiftEngine:stderr 31: <futures::stream::and_then::AndThen<S,F,U> as futures::stream::Stream>::poll +0ms
LiftEngine:stderr 32: <futures::stream::forward::Forward<T,U> as futures::future::Future>::poll +0ms
LiftEngine:stderr 33: <futures::future::map::Map<A,F> as futures::future::Future>::poll +0ms
LiftEngine:stderr 34: <futures::future::map_err::MapErr<A,F> as futures::future::Future>::poll +6ms
LiftEngine:stderr 35: futures::task_impl::std::set +0ms
LiftEngine:stderr 36: futures::task_impl::Spawn<T>::poll_future_notify +0ms
LiftEngine:stderr 37: std::panicking::try::do_call +0ms
LiftEngine:stderr 38: __rust_maybe_catch_panic +0ms
LiftEngine:stderr 39: tokio_threadpool::task::Task::run +0ms
LiftEngine:stderr 40: tokio_threadpool::worker::Worker::run_task +0ms
LiftEngine:stderr 41: tokio_threadpool::worker::Worker::run +0ms
LiftEngine:stderr 42: std::thread::local::LocalKey<T>::with +0ms
LiftEngine:stderr 43: std::thread::local::LocalKey<T>::with +1ms
LiftEngine:stderr 44: std::thread::local::LocalKey<T>::with +0ms
LiftEngine:stderr 45: tokio::runtime::threadpool::builder::Builder::build::{{closure}} +0ms
LiftEngine:stderr 46: std::thread::local::LocalKey<T>::with +0ms
LiftEngine:stderr 47: std::thread::local::LocalKey<T>::with +0ms
Please update the title and description to something that matches a feature request @pantharshit00 - including the current broken behavior as well is obviously fine.
Now I think about it, I would rather mark this as a bug.
https://github.com/prisma/prisma2/issues/384 is already an FR for MySQL 8. We can just highlight one of the bugs of that here.
I tracked this down to a problem in the migration engine, I'll link the PR once it's open :)
edit: as promised — https://github.com/prisma/prisma-engine/pull/47
This can probably be closed?
Yes, we've been testing on MySQL 8 for a long time, and nobody reported MySQL 8-specific difficulties, so as far as I know we have first-class support for it.
Most helpful comment
I tracked this down to a problem in the migration engine, I'll link the PR once it's open :)
edit: as promised — https://github.com/prisma/prisma-engine/pull/47