Add plants:import_categories for the ECHOcommunity plant migration - #119
Merged
Conversation
Creates missing plant categories and syncs membership. Categories share the
UUID convention: ECHOcommunity's Resource id for a category IS this
application's categories.id, which holds for all 14 categories the two systems
have in common, so no mapping table is needed.
Membership is not cosmetic - the GMCC selector gates on it, so a plant that
loses its category links disappears from that tool.
Additive by design: existing links are kept and missing ones added. Removing a
link is an editorial act, not a migration one.
Two details worth noting:
- Categories are built then saved rather than created, because name is a
required translated attribute and create! validates before the translation
can be applied.
- A dry run counts links belonging to categories it is about to create.
Otherwise it under-reports by the entire membership of every new category -
179 links for Bamboo alone, which made a dry run look far smaller than the
real change.
Rehearsed against staging: created the missing Bamboo category and 179 links,
bringing categories to parity at 15 and links to 815. The 8-link difference
against ECHOcommunity's 823 is explained - 11 of its rows point at plants that
do not exist, orphans in a join table with no foreign keys.
Full suite 2319 examples, 0 failures. Rubocop clean.
npflood
force-pushed
the
phase1/import-categories
branch
from
August 13, 2026 15:24
ce5fee7 to
1d38a5f
Compare
Contributor
Author
|
Rebased onto master to clear a conflict in #117 and this PR each add a line to the same Re-verified against merged master: 2,353 examples, 0 failures, whole-repo rubocop clean across 744 files. |
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
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.
Phase 1 of the plant-data ownership migration. Companion to #117 and #118, but
independent of both — merge in any order.
Creates missing plant categories and syncs membership from ECHOcommunity.
Categories share the UUID convention: ECHOcommunity's Resource id for a category
is this application's
categories.id. That holds for all 14 categories thetwo systems have in common, so no mapping table is needed.
Membership is not cosmetic. The GMCC selector gates on category membership,
so a plant that loses its links disappears from that tool entirely.
Behaviour worth reviewing
is an editorial act, not a migration one.
nameis a requiredtranslated attribute, so
create!validates beforeapply_translationshas achance to set it. That was a real failure, not a hypothetical one.
under-reports by the entire membership of every new category — 179 links for
Bamboo alone — making the dry run look far smaller than the actual change.
Rehearsed against staging
Created the missing Bamboo category (182 ECHOcommunity plants; it postdates
the 2020 export) and 179 links, bringing categories to parity at 15 and links to
815.
The 8-link difference against ECHOcommunity's 823 is fully explained: 11 of
its rows point at plants that do not exist — orphans in a join table that has
no primary key, no index and no foreign keys. They are unmigratable by
definition, so 812 is the correct number to carry across.