Seed provenance + inventory: source links and seed lots (#50) #64
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  steveandClaude Opus 4.8
|
94aed26e14 |
Address Gadfly review on seed lots
Build image / build-and-push (push) Successful in 15s
Three real bugs, two of which would have quietly corrupted inventory numbers. CopyGarden carried seed_lot_id into the copied plantings, so copying a garden double-counted the original lot's usage — the copy is a plan, not a second planting out of the same packet. It also quietly attached a private lot to a garden that may later be shared, contradicting the "lots are never shared with a garden" invariant this feature was built on. The copy now drops the link. RestorePlanting restored a seed_lot_id verbatim from a history snapshot. Live rows get their link nulled by ON DELETE SET NULL when a lot is deleted, but the snapshot still holds the old id, so undoing a planting deletion after retiring its lot would violate the foreign key and abort the whole revert. The revert now drops a dangling link before restoring: the plant really was in the ground, which is the part worth restoring. CreateSeedLot returned a lot with Used/Remaining at their zero values, so a packet you just bought reported "0 remaining" — the exact opposite of the truth. The version-conflict path had the same gap, and that row is what the client rebases on, so a 409 reporting remaining=0 is worse than no number at all. Both fill them now. Remaining can go negative and that is deliberate — it means more was planted than the lot recorded buying, which happens (a miscounted packet, a lot entered after the fact). Clamping to zero would hide the discrepancy at exactly the moment it is worth seeing. Now documented and tested rather than incidental. Performance and tidiness: SeedLotUsage is scoped to the lots being filled instead of scanning every planting the owner has, so reading one lot is one lot's work; ListSeedLotsForOwner gained the LIMIT every other list read has; parseNullable moved out of seed_lots.go into the shared request helpers, since every nullable field in the API needs that three-way absent/null/value distinction; finalizePlant validates against its own maxPlantVendorLen rather than borrowing a constant named for seed lots; seedLotForPlanting became checkSeedLotForPlanting, since it validates rather than fetches; and the duplicate intPtr test helper gave way to the existing ptrInt. Declined: recording seed-lot mutations in the revision history. change_sets are anchored to a garden and lots are user-scoped, deliberately — they belong to you, not to any one garden, so there is no garden to record them against. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |
||
|
steveandClaude Opus 4.8
|
5eedcaf945 |
Refuse deleting a plant that has seed lots
Build image / build-and-push (push) Successful in 4s
seed_lots.plant_id is ON DELETE CASCADE, so deleting a plant would have silently destroyed the purchase records attached to it — vendor, cost, germination rate, gone with no warning. Plantings were already guarded with ErrPlantInUse because their FK is RESTRICT; lots needed the same guard for the opposite reason, since their FK would have obliged rather than refused. Refusing lets the owner delete the lots deliberately if that is really what they meant, which is the same shape as the existing clones-and-edits path. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |
||
|
steveandClaude Opus 4.8
|
81481ede2f |
Seed provenance and inventory: source links and seed lots (#50)
"German Red Garlic" now links back to the Johnny's page it came from, and pansy knows how much is left. Two modelling calls, both of which look like omissions unless stated. The plant catalog stays FLAT — no species/variety hierarchy. A row in your catalog just is the thing you plant; the built-in "Garlic" is a generic starting point you clone. A hierarchy buys taxonomy nobody asked for and complicates every join. Inventory belongs to a PURCHASE, not to a variety. You might buy the same garlic from two vendors in two years at two prices and two germination rates; quantity columns on plants would collapse all of that into one number and lose it. So lots get their own table, and owner_id sits on the lot rather than being inherited from the plant — you can buy generic built-in Garlic from Johnny's and the record is still yours alone. Lots are never shared along with a garden. `remaining` is derived, never stored: quantity minus the summed effective count of the active plantings attributed to the lot. The alternative — decrementing a column when you plant — drifts the moment anything edits or removes a planting behind its back, and once it has drifted there's no way to tell what the true number was. Removing a plop gives the seed back with nothing having to remember to. The usage query returns raw radius/count/spacing rather than a SUM, because the effective-count formula lives in the service and reproducing it in SQL would guarantee the two drift apart. source_url is validated as http(s) with a host, on both plants and lots. It renders as a clickable link, so that check is load-bearing rather than tidiness: without it a stored javascript: URL becomes script execution the moment someone clicks it. Schemeless and relative URLs are refused too — they'd resolve against pansy's own origin, which is never what a vendor link means. A planting's lot must be the actor's AND a lot of the plant being planted. Attributing a garlic planting to a tomato lot would silently corrupt every remaining count downstream, so it's refused rather than stored, and re-checked on update in case a plant swap invalidated a previously-valid attribution. Deleting a lot leaves its plantings alone with a null link: the plants really were in the ground, whatever happened to the record of the packet. Closes #50 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |