Migration are failing for MySQL 8

[pantharshit00]

(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

[janpio]

Please update the title and description to something that matches a feature request @pantharshit00 - including the current broken behavior as well is obviously fine.

[pantharshit00]

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.

[tomhoule]

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

[janpio]

This can probably be closed?

[tomhoule]

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.