Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Going from 0.4.0 -> 0.6.0: requiring database changes? #9

Answered by CrawlerCode
AlecDusheck asked this question in Q&A
Discussion options

Just want to start off with- thank you for the awesome project, this is really useful.

We're currently running 0.4.0 on Payload 3.19.0. When we bumped our payload-authjs version from 0.4.0 to 0.6.0. After we bump, we get the following migration in our database (we're running Postgres):

import { MigrateUpArgs, MigrateDownArgs, sql } from '@payloadcms/db-vercel-postgres'
export async function up({ db, payload, req }: MigrateUpArgs): Promise<void> {
 await db.execute(sql`
 ALTER TABLE "users_sessions" DISABLE ROW LEVEL SECURITY;
 ALTER TABLE "users_verification_tokens" DISABLE ROW LEVEL SECURITY;
 DROP TABLE "users_sessions" CASCADE;
 DROP TABLE "users_verification_tokens" CASCADE;
 CREATE INDEX IF NOT EXISTS "users_accounts_provider_account_id_idx" ON "users_accounts" USING btree ("provider_account_id");
 CREATE UNIQUE INDEX IF NOT EXISTS "users_email_idx" ON "users" USING btree ("email");`)
}
export async function down({ db, payload, req }: MigrateDownArgs): Promise<void> {
 await db.execute(sql`
 CREATE TABLE IF NOT EXISTS "users_sessions" (
 	"_order" integer NOT NULL,
 	"_parent_id" varchar NOT NULL,
 	"id" varchar PRIMARY KEY NOT NULL,
 	"session_token" varchar NOT NULL,
 	"expires" timestamp(3) with time zone NOT NULL
 );
 
 CREATE TABLE IF NOT EXISTS "users_verification_tokens" (
 	"_order" integer NOT NULL,
 	"_parent_id" varchar NOT NULL,
 	"id" varchar PRIMARY KEY NOT NULL,
 	"token" varchar NOT NULL,
 	"expires" timestamp(3) with time zone NOT NULL
 );
 
 DROP INDEX IF EXISTS "users_accounts_provider_account_id_idx";
 DROP INDEX IF EXISTS "users_email_idx";
 DO $$ BEGIN
 ALTER TABLE "users_sessions" ADD CONSTRAINT "users_sessions_parent_id_fk" FOREIGN KEY ("_parent_id") REFERENCES "public"."users"("id") ON DELETE cascade ON UPDATE no action;
 EXCEPTION
 WHEN duplicate_object THEN null;
 END $$;
 
 DO $$ BEGIN
 ALTER TABLE "users_verification_tokens" ADD CONSTRAINT "users_verification_tokens_parent_id_fk" FOREIGN KEY ("_parent_id") REFERENCES "public"."users"("id") ON DELETE cascade ON UPDATE no action;
 EXCEPTION
 WHEN duplicate_object THEN null;
 END $$;
 
 CREATE INDEX IF NOT EXISTS "users_sessions_order_idx" ON "users_sessions" USING btree ("_order");
 CREATE INDEX IF NOT EXISTS "users_sessions_parent_id_idx" ON "users_sessions" USING btree ("_parent_id");
 CREATE INDEX IF NOT EXISTS "users_verification_tokens_order_idx" ON "users_verification_tokens" USING btree ("_order");
 CREATE INDEX IF NOT EXISTS "users_verification_tokens_parent_id_idx" ON "users_verification_tokens" USING btree ("_parent_id");`)
}

This is a little scary to me, just because I'm not super aware of what this does besides dropping some tables. I didn't see anything in the release notes either.

Is this something intentional? What side-effects will this have in production?

You must be logged in to vote

Previously, this plugin always added session and verification token tables. Starting from 0.5.0, the plugin determines whether you are using these features and adds the fields/tables conditionally. For this reason, the database schema is changed and you must create a migration. However, please check whether this is correct before migrating.

user_sessions

This is only required if you are using the Auth.js database session strategy (session.strategy = database). The default setting is jwt. Otherwise, this table is no longer required and could be removed.

users_verification_tokens

The verification tokens table is only required if you use Auth.js email provider / magic links. If you do not us...

Replies: 1 comment 2 replies

Comment options

Previously, this plugin always added session and verification token tables. Starting from 0.5.0, the plugin determines whether you are using these features and adds the fields/tables conditionally. For this reason, the database schema is changed and you must create a migration. However, please check whether this is correct before migrating.

user_sessions

This is only required if you are using the Auth.js database session strategy (session.strategy = database). The default setting is jwt. Otherwise, this table is no longer required and could be removed.

users_verification_tokens

The verification tokens table is only required if you use Auth.js email provider / magic links. If you do not use any of these providers, the table can also be deleted.

You must be logged in to vote
2 replies
Comment options

Thanks for the reply. We aren’t using either so makes sense why these are being dropped. Appreciate you explaining

Comment options

Thank you for your reference. I have added a info to the release notes :))

Answer selected by AlecDusheck
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet

AltStyle によって変換されたページ (->オリジナル) /