Going from 0.4.0 -> 0.6.0: requiring database changes?

[AlecDusheck]

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?

[CrawlerCode]

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.

[AlecDusheck]

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

[CrawlerCode]

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