Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(db-postgres): optionally allow to store blocks as JSON and add support for "in" operator within richText #6245

Open
wants to merge 8 commits into
base: beta
Choose a base branch
from

Conversation

r1tsuu
Copy link
Contributor

@r1tsuu r1tsuu commented May 7, 2024

Description

This PR adds option to store blocks as JSON column in Postgres with storeBlocksAsJSON property for the adapter.

While i like that you guys choose a hard, traditional way in implementing blocks with SQL, i think this may be not for everyone.

I like the strict approach to a schema when we talk about things like Users, Products, Orders etc.

But when it comes to a sites content it's different, not only that we can have too much things here (resulting into long table / constraints names, many joins on SELECT), it could also be changed frequently and you need to deal with a big migrations.

With Lexical blocks feature - they are stored in the same way, so i guess it's fine to allow that here too?

This PR also adds support for querying with in operator on richText and as well blocks when it's JSON.
This was done in order to pass as many tests as i can with storeBlocksAsJSON. And here's the result for "fields -> blocks"

image

Yes, not great here with querying on richtext, which is nested to already json blocks.

If this is something that will block this PR to merge, i have an idea on how we can improve overall our JSON queries, it could work for any nested structure. And JSON blocks, blocks in Lexical will work too.
This in theory could be achieved with this query:

CASE
WHEN jsonb_typeof(data) = 'array'  THEN

Why? we don't know in runtime, is current key object or array, because we don't know the structure when dealing with JSON field type. But with this Postgres JSON query way we can determine that.

In any way whatever separated PR or here i want to try implement this, because for now JSON / RichText querying isn't great in Payload.

p.s wrong base branch caused first commit, i reverted it.

  • I have read and understand the CONTRIBUTING.md document in this repository.

Type of change

  • New feature (non-breaking change which adds functionality)
  • This change requires a documentation update

Checklist:

  • I have added tests that prove my fix is effective or that my feature works
  • Existing test suite passes locally with my changes // with passing storeBlocksAsJSON: true 3 tests are failing.
  • I have made corresponding changes to the documentation

@AlessioGr AlessioGr added plugin: richtext-lexical @payloadcms/richtext-lexical plugin: richtext-slate @payloadcms/richtext-slate db-mongodb @payloadcms/db-mongodb labels May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
db-mongodb @payloadcms/db-mongodb plugin: richtext-lexical @payloadcms/richtext-lexical plugin: richtext-slate @payloadcms/richtext-slate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants