Migrate: Do not drop PostGIS table

Created on 29 Jul 2019 · 9Comments · Source: prisma/migrate

PostGIS requires spatial_ref_sys table which Prisma is trying to drop when performing the initial migration

kinimprovement tecengines

Source

pantharshit00

👍6

Most helpful comment

Current workaround is to define that table in the schema like so:

model SpatialRefSy {
  srid      Int     @id
  authName  String? @map("auth_name")
  authSrid  Int?    @map("auth_srid")
  proj4text String?
  srtext    String?

  @@map("spatial_ref_sys")
}

But having out of the box support would be nice as PostGIS is pretty frequent used

pantharshit00 on 29 Jul 2019

👍7

All 9 comments

Current workaround is to define that table in the schema like so:

model SpatialRefSy {
  srid      Int     @id
  authName  String? @map("auth_name")
  authSrid  Int?    @map("auth_srid")
  proj4text String?
  srtext    String?

  @@map("spatial_ref_sys")
}

But having out of the box support would be nice as PostGIS is pretty frequent used

pantharshit00 on 29 Jul 2019

👍7

hey guys I'm pretty new to prisma2, but I'm really curious about it: I tried introspect on an existing PostGIS DB but the generated schema is missing all geometry fields in the generated TS entities.
Is there any recommendation to include geometry and geography types in a Prisma2 schema?

lamuertepeluda on 25 Nov 2019

I also don't know if this is related, but:

prisma2 dev

Error

Error: Error in migration engine: [2019-11-25T13:49:14Z INFO  quaint
::pool] Starting a PostgreSQL pool with 9 connections.
thread 'tokio-runtime-worker-0' panicked at 'type 'geometry' is not
supported here yet.', libs/sql-schema-describer/src/postgres.rs:528:
14
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core:
:fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: migration_engine::main::{{closure}}
   6: std::panicking::rust_panic_with_hook
   7: std::panicking::begin_panic
   8: core::ops::function::impls::<impl core::ops::function::FnOnce<
A> for &mut F>::call_once
   9: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  10: sql_schema_describer::postgres::SqlSchemaDescriber::get_table
  11: <core::iter::adapters::Map<I,F> as core::iter::traits::iterato
r::Iterator>::fold
  12: <sql_schema_describer::postgres::SqlSchemaDescriber as sql_sch
ema_describer::SqlSchemaDescriberBackend>::describe
  13: <sql_migration_connector::sql_database_migration_inferrer::Sql
DatabaseMigrationInferrer as migration_connector::database_migration
_inferrer::DatabaseMigrationInferrer<sql_migration_connector::sql_mi
gration::SqlMigration>>::infer
  14: <migration_engine::api::MigrationApi<C,D> as migration_engine:
:api::GenericApi>::infer_migration_steps
  15: migration_engine::api::rpc::RpcApi::create_sync_handler
  16: tokio_executor::enter::exit
  17: tokio_threadpool::blocking::blocking
  18: <futures::future::lazy::Lazy<F,R> as futures::future::Future>:
:poll
  19: futures::future::chain::Chain<A,B,C>::poll
  20: <futures::future::then::Then<A,B,F> as futures::future::Future
>::poll
  21: <futures::future::lazy::Lazy<F,R> as futures::future::Future>:
:poll

lamuertepeluda on 25 Nov 2019

Hi,

Currently, we do not have custom database types support. But we are working on a spec for that here: https://github.com/prisma/specs/pull/291

This will enable you to use custom data types like geometry

pantharshit00 on 27 Nov 2019

@pantharshit00 is there a workaround for the geometry type yet? A hacky one would be sufficient

John0x on 10 Feb 2020

👍4

https://github.com/prisma/prisma-engines/pull/773 was merged yesterday, it will make migrate ignore the PostGIS system tables. I think this issue can be closed once this is released.