[v0/v1 migration] Add fixed ordering for top-level hierarchy nodes#6238
Conversation
…nd add a fallback safety check for the comparison.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses non-deterministic rendering of top-level hierarchy nodes caused by the migration to Spanner. By introducing a pinned ordering configuration, the front end now enforces a consistent, production-aligned display order for root nodes, regardless of the order returned by the API. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request implements a configurable pinned order for top-level nodes in the statistical variable hierarchy and updates the configuration logic to merge default settings with global overrides. The review feedback identifies an opportunity to generalize the sorting logic by removing a specific check for the "dc/g/Root" node, ensuring that the pinned order and alphabetical sorting are applied consistently across different hierarchy roots.
… pinning order is, apply it).
…to the mock results in the hierarchy).
There was a problem hiding this comment.
Should this also be updated to index 1?
Issue
http://b/505060318
Description
The front end was previously rendering the top level of the stat var hierarchy in the order returned by the API. From the perspective of both mixer and the website, this order was effectively non-deterministic (i.e., the order was not being enforced in either mixer or the website), and was therefore being effectively curated upstream.
With the migration to Spanner, the order being returned was no longer the same.
With this PR, we are now enforcing Data Commons root nodes to be pinned in the order that matches the current production site (rather than relying on an arbitrary order from the database).
Screenshots
Before
After