Store term localizations as separate rows #580
Draft
ryanmitchell wants to merge 3 commits into5.xfrom
Draft
Conversation
Replaces the previous approach of embedding localizations in the canonical row's `data->localizations` JSON field. Each locale now gets its own row (origin = null for canonical, origin = canonical_id for translations), enabling real WHERE site = ? queries. - Add migration to add nullable `origin` column to taxonomy_terms - Add data migration to move existing JSON localizations to own rows - TermQueryBuilder: drop $site property; add siteFilterApplied flag and applyOriginFilter() so default queries return one row per term; preload all locale rows in transform() to avoid N+1 - Term::fromModel() accepts preloaded sibling rows; builds locale data from per-row storage with fallback for legacy JSON localizations - Term::makeModelFromContract() writes canonical row only (no localizations key) - TermRepository::save() writes per-locale rows after the canonical model - TermRepository::delete() removes all locale rows for a term - ImportTaxonomies: saves locale rows after canonical on import - ExportTaxonomies: reads canonical rows + sibling locale rows on export - Update tests to reflect new per-row storage model Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
TermQueryBuilder::transform() preloads locale rows and stores them in Blink keyed by taxonomy::slug. Term::fromModel() reads from Blink when available and falls back to a direct DB query otherwise, keeping the method signature unchanged. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
Author
|
@duncanmcclean this is likely a breaking change given the underlying storage changes. what do you think? |
Member
|
I like the idea. It would certainly make localizations easier to query. However, as you say, it's likely a breaking change so it'll probably need to wait until the next major release, whenever that is (probably Q1, alongside v7) 😞. |
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
2 participants
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.
Previously, all locale data for a term was embedded in a single database row under a data->localizations JSON key. This made it impossible to query terms by site using a real WHERE site = ? clause, since translations stored inside a row's JSON are invisible to SQL.
This PR moves each localization to its own database row. The canonical (default-locale) row keeps origin = NULL, and each translation row stores origin = <canonical_id>.
This aligns with how entries already work.
Closes #578