Point staging Solr at the shared modelseed.org instance - #235
Merged
Conversation
Solr is not deployed per-site the way the other backends are. A single instance at modelseed.org/solr hosts both core sets -- reactions/ compounds/structures and their *_staging twins -- and it is the only instance running the Solr 9 nested-document schema that this build queries (child docs for stoichiometry/thermodynamics, atom_mapping). staging.modelseed.org/solr is a separate, older deployment: reactions_ staging holds 56,017 docs against 459,198 on the shared instance, the schema is still flat (parent-level stoichiometry/deltag/deltagerr, no doc_type, no atom_mapping), and a [child] query returns the pre-Solr-9 error "Parent filter should be sent as parentFilter=filterCondition". Staging builds pointed at it therefore render stale data and lose every nested-schema feature. Set the staging default and the hardcoded fallback to the shared instance so staging and production differ only in collection names (reactions_staging vs reactions), which the shared instance serves. Verified against a local staging-mode build: reaction and compound pages resolve nested children and atom mapping, and the endpoint returns access-control-allow-origin: *, so no proxy rewrite is needed.
VibhavSetlur
added a commit
to VibhavSetlur/ModelSEED-UI
that referenced
this pull request
Aug 28, 2026
…ging base Fix a pre-existing semantic conflict where PR ModelSEED#233 merged after PR ModelSEED#235 (e788d98) without it, leaving expectations naming staging.modelseed.org/solr. The reactions_staging collection name is unchanged because the shared instance serves both core sets.
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.
Solr is not deployed per-site the way the other backends are. A single instance at modelseed.org/solr hosts both core sets -- reactions/ compounds/structures and their *_staging twins -- and it is the only instance running the Solr 9 nested-document schema that this build queries (child docs for stoichiometry/thermodynamics, atom_mapping).
staging.modelseed.org/solr is a separate, older deployment: reactions_ staging holds 56,017 docs against 459,198 on the shared instance, the schema is still flat (parent-level stoichiometry/deltag/deltagerr, no doc_type, no atom_mapping), and a [child] query returns the pre-Solr-9 error "Parent filter should be sent as parentFilter=filterCondition". Staging builds pointed at it therefore render stale data and lose every nested-schema feature.
Set the staging default and the hardcoded fallback to the shared instance so staging and production differ only in collection names (reactions_staging vs reactions), which the shared instance serves.
Verified against a local staging-mode build: reaction and compound pages resolve nested children and atom mapping, and the endpoint returns access-control-allow-origin: *, so no proxy rewrite is needed.