fix(core): ne pas relayer order-by en tri serveur sur une colonne issue d'unpivot#410
Merged
Merged
Conversation
…ue d'unpivot (#394) La négociation serveur de dsfr-data-query atteignait l'adapter Grist à travers la délégation transparente getAdapter() des transformateurs et poussait l'order-by en ?sort= serveur, alors que la colonne triée (annee) était créée côté client par dsfr-data-unpivot → 500 unknown key, source partagée en erreur pour tous ses abonnés. Nouveau hook optionnel transformsSchema() sur le contrat SourceElement : unpivot répond toujours true, normalize répond true si rename/compute/ flatten/lowercase-keys (sinon délègue à son amont). Quand la chaîne transforme le schéma, dsfr-data-query ne délègue plus rien au serveur — order-by, group-by et where s'exécutent client-side sur les données post-transformation. Fixes #394 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Résumé
Quand une
dsfr-data-queryporte unorder-bysur une colonne créée en aval de la source (ex.annee, produite pardsfr-data-unpivot), la négociation serveur atteignait l'adapter Grist à travers la délégation transparentegetAdapter()des transformateurs et poussait le tri en?sort=anneecôté serveur. La colonne n'existant pas dans la table Grist (format widec2017…c2026), l'API répondait 500unknown key anneeet la source partagée tombait en erreur pour tous ses abonnés (charts, KPI).Correctif
Piste 1 de l'issue : tri client systématique quand la chaîne transforme le schéma.
transformsSchema()sur le contratSourceElement(packages/core/src/utils/source-element.ts) : true si le composant (ou un transformateur en amont de lui) crée/renomme des colonnes par rapport au schéma de la source qui fetch.dsfr-data-unpivot: répond toujourstrue(créevar-name/value-name, supprime les colonnes dépliées).dsfr-data-normalize: répondtruesirename/compute/flatten/lowercase-keyssont actifs ; sinon délègue le statut à son amont (couvre la chaînenormalize → unpivot → source).dsfr-data-query.\_negotiateServerSide(): quand l'amont transforme le schéma, aucune délégation serveur (order-by, mais aussi group-by/aggregate/where — mêmes noms de colonnes post-transformation, même 500). Tout s'exécute client-side sur les données transformées.Une query branchée directement sur une source (ou derrière un normalize purement « valeurs » :
numeric-auto,trim…) continue de déléguer comme avant — non-régression couverte par un test de contrôle.Tests
tests/query-orderby-unpivot.test.ts(9 tests) : repro du bug (l'order-by n'atteint plus la source), repli en tri client post-unpivot, extension à where/group-by, contrôle de non-régression sur la délégation directe, et statutstransformsSchema()sur la chaîne.dsfr-datainclus.Fixes #394
🤖 Generated with Claude Code