payload
payload copied to clipboard
payloadcms
db-postgres & Supabase: drizzle detects schema changes when there are none
Link to reproduction
No response
Describe the Bug
See https://discord.com/channels/967097582721572934/1183518316191568023/1183518316191568023 :
npm run dev runs mostly fine, but then I receive the following message:
? Warnings detected during schema push:
· You're about to set not-null constraint to email column without default, which contains 1 items
DATA LOSS WARNING: Possible data loss detected if schema is pushed.
Accept warnings and push schema to database? › (y/N)
When I select no, then the startup process terminates. When I select yes, then I lose my user data. Where can I read documentation on what exactly happens during npm run dev? Is it necessary to push the database schema even though there haven't been any changes in between runs (with the exception of my creation of a user)?
To Reproduce
This only seems to happen on supabase
Payload Version
?
Adapters and Plugins
No response
To Reproduce
Just install Payload and use Supabase for PostgreSQL, simple as that
Payload Version
My packages:
"dependencies": {
"@payloadcms/bundler-webpack": "^1.0.0",
"@payloadcms/plugin-cloud": "^2.0.0",
"@payloadcms/richtext-slate": "^1.0.0",
"cross-env": "^7.0.3",
"dotenv": "^8.2.0",
"express": "^4.17.1",
"payload": "^2.0.0",
"@payloadcms/db-postgres": "^0.x"
},
Additional Commentary
Env has nothing beyond supabase link for db and secret key
Same issue, connecting to Supabase.
I don't have a solution, but the warning is coming from db-postgres>dist>connect.js Payload is using Drizzle under the hood, and drizzle is set to always push the schema if not in prod. (connect.js : 43)
Looking at the postgresAdapter (db-postgres>dist>index.js), push can be passed as an arg from your payload.config.ts, and disabled like so:
db: postgresAdapter({
pool: {
connectionString: process.env.DATABASE_URI,
},
push: false,
}),
I am having the same issue when using the postgresAdapter in the blank payload template with supabase.
For me, this makes the postgresAdapter unusable because every time I change my collection schema, it not only wants these schema changes to push but also the email one which clears my whole users table.
? Warnings detected during schema push:
· You're about to set not-null constraint to email column without default, which contains 1 items
· ... my other schema changes
DATA LOSS WARNING: Possible data loss detected if schema is pushed.
Accept warnings and push schema to database? » (y/N)
Using push: false is not really an option if you are adding new fields. I suppose we will need to wait until this is out of beta. 😄
Does anyone know what Supabase is doing differently that trigger this data loss?
I just tried to replicate this issue on the latest version of Payload and was not able to since we updated the dependency of drizzle.
Tested on:
[email protected]
@payloadcms/[email protected]
Inherited dependency:
[email protected]
Please @DanRibbens (me) if you still experience an issue and I'll reopen.
Hello @DanRibbens, I just tested with the same version as you for drizzle, db-postgres & payload and i have still the same message: DATA LOSS WARNING: Possible data loss detected if schema is pushed. I tested with npm run dev & yarn dev on a docker, same result. I use a free railway db in the meantime and it works with this one.
Same for me, Supabase Postgres. I added "push: false" which let's me work for now. Hoping this helps with visibility.
@richleach Yes, they determined this is likely a bug on Supabase's end. Gathering all needed info to open an issue right now.
After a few investigations, it's actually not a bug on the Supabase side, but Drizzle needed an update. I have already fixed that locally. I'm going to run a few more tests and then send an updated tag to the Payload team for upgrading
So grateful to see all this teamwork to solve the issue, thx so much. I really believe a lot in Payload.
Appreciate the fix for this @denolfe. Would it be possible to get a version bump on the @payload/db-postgres package? We're not able to test this fix atm. Thank you!
