hi all, we have an app where we want a hybrid of p...
# orm-help
c
hi all, we have an app where we want a hybrid of prisma-managed postgres tables and non-prisma managed tables. the latter category is primarily because we’re doing some detailed sql stuff that prisma isn’t yet able to support. we’re running into an issue where prisma seems very eager to delete tables that aren’t mapped in our schema.prisma file. i see a
--create-only
migrate flag that does a dry run for schema migrations but i’m wondering if there’s also a
--dont-delete-tables-you-dont-know-about-pretty-please
flag as well?
c
possibly. would that require us to provide mappings for all the tables in the schema even if we don’t plan to ever access them via primsa?
btw, i’m headed to a few meetings but will try to check back later this afternoon to pick up the convo if there’s more here
d
I believe so, I haven't used this feature myself
I think you can introspect and then mark the tables as ignored
c
cool, that was going to be my workaround recommendation to the team
it’d be nice if you could maintain an introspected-schema.prisma and schema.prisma and just import one to the other
keeping them in the same place makes diffs, reviews and migrations a little harder to review
i saw a reference in the
@prisma/migrate
readme to a before and after hook for migrations. i’m wondering if we could use that to do something like this: 1. run an introspection to an introspected.prisma file 2. compare the tables and fields under introspection with the ones in our primary
schema.prisma
3. merge our
schema.prisma
with the remaining tables from
introspected.prisma
tables (appending @@ignore inside each of those tables) 4. running the migration against the merged prisma schema file
but i don’t know if migration hooks got dropped at some point. i only see the reference on npm on version 2.3.0-dev from a year ago
r
@cedric 👋 Currently that’s not possible as the Migrate expects the database to map to the tables defined in
schema.prisma
. There’s a feature request for the same that you can add a 👍 on and your use case as well. For now, I would suggest using introspection as you have tables not just being managed by Prisma.
c
thanks
we actually did find a workaround where we just migrated the non-prisma-managed tables over to a separate schema
the
?schema=my_schema
parameter seems to be undocumented in both the prisma docs and the libpq url scheme that the prisma docs point to
but it appears to work regardless
actually, on second glance, it is documented. it’s just hard to search for bc “schema” is pretty widely referenced as
schema.prisma