proof of concept: custom indexing in schemas#25767
Draft
innerdvations wants to merge 8 commits intodevelopfrom
Draft
proof of concept: custom indexing in schemas#25767innerdvations wants to merge 8 commits intodevelopfrom
innerdvations wants to merge 8 commits intodevelopfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Size Change: 0 B Total Size: 2.9 MB ℹ️ View Unchanged
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does it do?
Just playing around with some ideas for allowing custom indexes. This PR uses the existing and unsupported "indexes" property in a content type to add support for indexes targeting attributes (not database columns).
Basic indexes are simple and are supported via the examples in the included contributor documentation.
The biggest challenge (and still in progress / discussion) is allowing useful "unique" indexes -- with our current document model, that is impossible, and attempting to add a unique index to a content type table will break your Strapi.
So this PR demonstrates the automatic (non-breaking) creation of a new database structure, where we can define document-level attributes that are the same across all locales (but can differ by publication state) and locale-level attributes. It then becomes possible to enforce unique constraints at the database level.
In its current state, this PR is not ideal, but attempts to be minimally invasive, because it will only create the columns or tables necessary based on if it's necessary for a unique index (ie, for a unique global attribute we create a new table, and for a unique locale attribute we add a new column)
In reality, we should automatically create all columns and tables to support this universally, and allow defining an attribute as locale or global within itself, and then we wouldn't have to define a scope on the unique index; it would know just from what type of attribute it is. Defining it in the attribute itself would also allow us to give context to the front-end to let the users know on document-level values that changing it in one locale will change it in every locale.
Why is it needed?
Has been one of the top requested features for years:
https://feedback.strapi.io/developer-experience/p/custom-indexes-in-the-schema
How to test it?
Provide information about the environment and the path to verify the behaviour.
Related issue(s)/PR(s)
Let us know if this is related to any issue/pull request