better handling of textarea to richText field conversion

[MinSomai]

I had a textarea field which I had to change to richText because I wanted links. And because I had previous values in that same name. The admin goes white and show nothing.

Uncaught Error: [Slate] value is invalid! Expected a list of elements but got: "previous textarea value"

[jmikrut]

Hey @MinSomai — yes, if you have old string-based data saved in a field, you'll need to migrate your old textarea field data to the JSON format that the RichText field stores.

You can write a migration script using the Payload Local API to find all documents with old textarea data, and then update each one to use the new data shape.

Here is an example of a seed script that we are using in our public demo, which you could modify to migrate your old data to your new shape:

https://github.com/payloadcms/public-demo/blob/master/src/cron/reset.ts

You'd basically need to take data like this:

'some string stored in a textarea field'

and change it the RichText JSON format like this:

{
  children: [
    {
      text: 'some string stored in a textarea field'
    }
  ]
}

[MinSomai]

oh okay. shouldn't this come with the framework itself?

[jmikrut]

Not necessarily, because the developer should be responsible for their own database schema and structure. Just like migrations with SQL-based databases. Even with something like Prisma—if you change your schema, you need to write a migration.

Imagine if you accidentally changed or removed a field from your schema. If Payload automatically deleted the data, or if Payload automatically migrated the data, that could be hugely unexpected. Instead, it should be declarative.

Being that Payload is NoSQL-based, you don't need to write migrations. It's up to you!

[AlessioGr]

Not necessarily, because the developer should be responsible for their own database schema and structure. Just like migrations with SQL-based databases. Even with something like Prisma—if you change your schema, you need to write a migration.

Imagine if you accidentally changed or removed a field from your schema. If Payload automatically deleted the data, or if Payload automatically migrated the data, that could be hugely unexpected. Instead, it should be declarative.

Being that Payload is NoSQL-based, you don't need to write migrations. It's up to you!

What about adding an option to enable automatic migrations? I really don't know a lot about it, but I saw “Automatic db migrations with Prisma” on the keystonejs.com website – so there appears to be some kind of automatic migrations in Prisma?

[DanRibbens]

We aren't using Prisma and it would be a significant effort to integrate and leverage the features it has.

I would look first at doing this with a mongoose specific migration tool such as https://www.npmjs.com/package/migrate-mongoose

If it works well enough we could document or add code/processes to Payload to officially support migrations.
I would love it if somebody has time and wants to try it out and share what they learn in a PoC repo.

There is some danger in automatic migrations especially if your doing considerable work on a large DB so it would need to have separate commands from start.