6db07f0c03e6e371df4e40263d7a26484d053667
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Alessio Gravili
|
a6f7ef837a |
feat(db-*): export types from main export (#11914)
In 3.0, we made the decision to export all types from the main package export (e.g. `payload/types` => `payload`). This improves type discoverability by IDEs and simplifies importing types. This PR does the same for our db adapters, which still have a separate `/types` subpath export. While those are kept for backwards-compatibility, we can remove them in 4.0. |
||
|
Sasha
|
b73fc586b8 |
feat: expose session, db in migrations to use the active transaction with the database directly (#9849)
This PR adds a feature which fixes another issue with migrations in
Postgres and does few refactors that significantly reduce code
duplication.
Previously, if you needed to use the underlying database directly in
migrations with the active transaction (for example to execute raw SQL),
created from `payload create:migration`, as `req` doesn't work there you
had to do something like this:
```ts
// Postgres
export async function up({ payload, req }: MigrateUpArgs): Promise<void> {
const db = payload.db.sessions?.[await req.transactionID!].db ?? payload.db
const { rows: posts } = await db.execute(sql`SELECT * from posts`)
}
// MongoDB
export async function up({ payload, req }: MigrateUpArgs): Promise<void> {
const session = payload.db.sessions?.[await req.transactionID!]
const posts = await payload.db.collections.posts.collection.find({ session }).toArray()
}
```
Which was:
1. Awkward to write
2. Not documented anywhere
Now, we expose `session` and `db` to `up` and `down` functions for you:
#### MongoDB:
```ts
import { type MigrateUpArgs } from '@payloadcms/db-mongodb'
export async function up({ session, payload, req }: MigrateUpArgs): Promise<void> {
const posts = await payload.db.collections.posts.collection.find({ session }).toArray()
}
```
#### Postgres:
```ts
import { type MigrateUpArgs, sql } from '@payloadcms/db-postgres'
export async function up({ db, payload, req }: MigrateUpArgs): Promise<void> {
const { rows: posts } = await db.execute(sql`SELECT * from posts`)
}
```
#### SQLite:
```ts
import { type MigrateUpArgs, sql } from '@payloadcms/db-sqlite'
export async function up({ db, payload, req }: MigrateUpArgs): Promise<void> {
const { rows: posts } = await db.run(sql`SELECT * from posts`)
}
```
This actually was a thing with Postgres migrations, we already were
passing `db`, but:
1. Only for `up` and when running `payload migrate`, not for example
with `payload migrate:fresh`
2. Not documented neither in TypeScript or docs.
By ensuring we use `db`, this also fixes an issue that affects all
Postgres/SQLite migrations:
Currently, if we run `payload migration:create` with the postgres
adapter we get a file like this:
```ts
import { MigrateUpArgs, MigrateDownArgs, sql } from '@payloadcms/db-postgres'
export async function up({ payload, req }: MigrateUpArgs): Promise<void> {
await payload.db.drizzle.execute(sql`
CREATE TABLE IF NOT EXISTS "users" (
"id" serial PRIMARY KEY NOT NULL,
);
```
Looks good?
Not exactly!
`payload.db.drizzle.execute()` doesn't really use the current
transaction which can lead to some problems.
Instead, it should use the `db` from `payload.db.sessions?.[await
req.transactionID!].db` because that's where we store our Drizzle
instance with the transaction.
But now, if we generate `payload migrate:create` we get:
```ts
import { MigrateUpArgs, MigrateDownArgs, sql } from '@payloadcms/db-postgres'
export async function up({ db, payload, req }: MigrateUpArgs): Promise<void> {
await db.execute(sql`
CREATE TABLE IF NOT EXISTS "users" (
"id" serial PRIMARY KEY NOT NULL,
);
```
Which is what we want, as the `db` is passed correctly here:
|
||
|
Dan Ribbens
|
edfa85bcd5 |
feat(db-postgres)!: relationship column (#6339)
BREAKING CHANGE: Moves `upload` field and `relationship` fields with `hasMany: false` & `relationTo: string` from the many-to-many `_rels` join table to simple columns. This only affects Postgres database users. ## TL;DR We have dramatically simplified the storage of simple relationships in relational databases to boost performance and align with more expected relational paradigms. If you are using the beta Postgres adapter, and you need to keep simple relationship data, you'll need to run a migration script that we provide you. ### Background For example, prior to this update, a collection of "posts" with a simple `hasMany: false` and `relationTo: 'categories'` field would have a `posts_rels` table where the category relations would be stored. This was somewhat unnecessary as simple relations like this can be expressed with a `category_id` column which is configured as a foreign key. This also introduced added complexity for dealing directly with the database if all you have are simple relations. ### Who needs to migrate You need to migrate if you are using the beta Postgres database adapter and any of the following applies to you. - If you have versions enabled on any collection / global - If you use the `upload` field - If you have relationship fields that are `hasMany: false` (default) and `relationTo` to a single category ([has one](https://payloadcms.com/docs/fields/relationship#has-one)) relations ### We have a migration for you Even though the Postgres adapter is in beta, we've prepared a predefined migration that will work out of the box for you to migrate from an earlier version of the adapter to the most recent version easily. It makes the schema changes in step with actually moving the data from the old locations to the new before adding any null constraints and dropping the old columns and tables. ### How to migrate The steps to preserve your data while making this update are as follows. These steps are the same whether you are moving from Payload v2 to v3 or a previous version of v3 beta to the most recent v3 beta. **Important: during these steps, don't start the dev server unless you have `push: false` set on your Postgres adapter.** #### Step 1 - backup Always back up your database before performing big changes, especially in production cases. #### Step 2 - create a pre-update migration Before updating to new Payload and Postgres adapter versions, run `payload migrate:create` without any other config changes to have a prior snapshot of the schema from the previous adapter version #### Step 3 - if you're migrating a dev DB, delete the dev `push` row from your `payload_migrations` table If you're migrating a dev database where you have the default setting to push database changes directly to your DB, and you need to preserve data in your development database, then you need to delete a `dev` migration record from your database. Connect directly to your database in any tool you'd like and delete the dev push record from the `payload_migrations` table using the following SQL statement: ```sql DELETE FROM payload_migrations where batch = -1` ``` #### Step 4 - update Payload and Postgres versions to most recent Update packages, making sure you have matching versions across all `@payloadcms/*` and `payload` packages (including `@payloadcms/db-postgres`) #### Step 5 - create the predefined migration Run the following command to create the predefined migration we've provided: ``` payload migrate:create --file @payloadcms/db-postgres/relationships-v2-v3 ``` #### Step 6 - migrate! Run migrations with the following command: ``` payload migrate ``` Assuming the migration worked, you can proceed to commit this change and distribute it to be run on all other environments. Note that if two servers connect to the same database, only one should be running migrations to avoid transaction conflicts. Related discussion: https://github.com/payloadcms/payload/discussions/4163 --------- Co-authored-by: James <james@trbl.design> Co-authored-by: PatrikKozak <patrik@payloadcms.com> |