https://www.prisma.io/ logo
Join Slack
Powered by
Hello. We have a Postgres database running on Citu...
# orm-help
e
Hello. We have a Postgres database running on Citus, which technically supports 
FOREIGN KEY
constraints. But in practice, it's very hard to make them work. Is there any way to use things like 
db pull
and Prisma joins without actually having 
FOREIGN KEY
constraints? For example, could 
db pull
be convinced to ignore manually-added relations? Or is this basically hopeless? Thank you for any advice you can provide!
r
We are working on this request, so at the moment you can try this workaround.
e
Thank you! Investigating this workaround now. We are most interested in having 
db pull
preserve manually added relations. We don't use `migrate`; we have another tool for that. I'll follow up shortly with the result of trying this. Thanks!
šŸ‘ 1
Unfortunately, with Prisma 2.30.3 and 
previewFeatures = ["planetScaleMode"]
set, 
prisma db pull
still removes any relation fields and 
@relation
attributes that I've added manually. šŸ˜ž I could try writing a script to re-insert all of these fields after each 
db pull
, but that would be rather clunky. The underlying problem is that Citus struggles with 
FOREIGN KEY
relationships on distributed tables. It can be made to work (most of the time!) if the foreign key relationships are carefully created in the right order, but sometimes it's necessary to completely recreate distributed production tables to add a constraint. Thank you for the suggestion!
Ideally, it would be possible to declare relationships manually, and have them preserved by 
db pull
if the underlying database doesn't fully support 
FOREIGN KEY
constraints.
r
Did you add the flag to the datasource as well?
e
If I add it to the datasource, I get:
Copy code
Error: Get config: Schema Parsing P1012

error: Preview features are only supported in the generator block. Please move this field to the generator block.
  -->  schema.prisma:9
   | 
 8 |   url             = "<postgres://postgres@localhost:15432/postgres>"
 9 |   previewFeatures = ["planetScaleMode"]
   | 

Validation Error Count: 1
(Prisma 2.30.3)
r
You need to add 
planetScaleMode = true
to the datasource.
e
Oh, OK. Sorry, I misunderstood. When I try with:
Copy code
datasource db {
  provider        = "postgresql"
  url             = "<postgres://postgres@localhost:15432/postgres>"
  planetScaleMode = true
}
...then 
db pull
deletes the 
planetScaleMode = true
line from the output.
Maybe this only works for MySQL/PlanetScale?
r
Iā€™m not sure, @janpio might know better.
j
That might be true but unexpected.
Did you add both - the preview feature flag in the generator and the property in the datasource?
e
Yup!
j
Can you quickly open an issue about this?
We should try to reproduce this and see what is going on.
In the next or the one after the next release, there will be a rework of the "no foreign keys" mode that moves this clearly out of context of PlanetScale and MySQL - but it really is just a rename under the hood so knowing what is going on here might be useful asap.
e
I'll open an issue. Here's what happens:
Copy code
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["planetScaleMode"]
}

datasource db {
  provider        = "postgresql"
  url             = "<postgres://postgres@localhost:15432/postgres>"
  planetScaleMode = true
}
After `npx prisma db pull`:
Copy code
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["planetScaleMode"]
}

datasource db {
  provider = "postgresql"
  url      = "<postgres://postgres@localhost:15432/postgres>"
}
šŸ‘ 1
@janpio Here's the issue: https://github.com/prisma/prisma/issues/9253 Thank you for looking into this!
j
Thanks!
The relations being removed is probably expected right now, our issue that will solve this is https://github.com/prisma/prisma/issues/9147
But the configuration being removed surprises me and I will confirm later today.
e
Well, remember this is PostgreSQL (Citus) and not MySQL.
j
Yep, exactly what I never tried and will do later to make sure this is not affected by that. Might really be an oversight.
So you see, your original request is not well supported yet by Prisma. If you write stuff manually it should work, but then some commands do not properly honor that.
But we are actively working on this right now, so expect improvements right now - also informed by your issue šŸ’š
e
Yeah, it looks like I'll need to write a tool to manually patch up 
schema.prisma
after every 
prisma db pull
, at least for now. Thank you for looking into this!
j
Don't spend to much time on it - might be solved next Tuesday or 2 weeks later.
(I use a visual Git UI for this reason tbh - the schema is very easy to fix that way)
šŸ™Œ 1
Open in Slack
PreviousNext
Powered by