Closed JoeCohen closed 3 months ago
It's also fails to update Projects, leaving a broken reference there. Perhaps need some meta-programming/reflection in tests to assure that:
location
changes.Thanks, Joe. Interesting that check_for_broken_references didn't find that. Every association should look like "belongs to" somewhere. Many-to-many has to have a glue table, each of whose records will "belong to" both of the original tables, for example. And so on. So why wasn't check_for_broken_references picking up that association and therefore noticing the broken reference between project and the missing location?
On Tue, Apr 2, 2024 at 11:30 AM Joseph D. Cohen @.***> wrote:
It's also fails to update Projects, leaving a broken reference there. Perhaps need some meta-programming/reflection in tests to assure that:
- There's fixture for each class that could be affected by a location merger
- The fixture's location changes.
— Reply to this email directly, view it on GitHub https://github.com/MushroomObserver/mushroom-observer/issues/2084#issuecomment-2032372926, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYTNNIEZIMZLOX4KKIHPHDY3LFJBAVCNFSM6AAAAABFSC2Q26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSGM3TEOJSGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
It didn't find it because there's not yet any such broken reference. There's no Project whose Location was merged after the Project was created. (There are only 7 Project's with a non-nil location.)
On Tue, Apr 2, 2024 at 10:22 AM Jason Hollinger @.***> wrote:
Thanks, Joe. Interesting that check_for_broken_references didn't find that. Every association should look like "belongs to" somewhere. Many-to-many has to have a glue table, each of whose records will "belong to" both of the original tables, for example. And so on. So why wasn't check_for_broken_references picking up that association and therefore noticing the broken reference between project and the missing location?
On Tue, Apr 2, 2024 at 11:30 AM Joseph D. Cohen @.***> wrote:
It's also fails to update Projects, leaving a broken reference there. Perhaps need some meta-programming/reflection in tests to assure that:
- There's fixture for each class that could be affected by a location merger
- The fixture's location changes.
— Reply to this email directly, view it on GitHub < https://github.com/MushroomObserver/mushroom-observer/issues/2084#issuecomment-2032372926>,
or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAYTNNIEZIMZLOX4KKIHPHDY3LFJBAVCNFSM6AAAAABFSC2Q26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSGM3TEOJSGY>
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/MushroomObserver/mushroom-observer/issues/2084#issuecomment-2032623115, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALDFDVP7J7AFXZBQLGJW3Y3LSMRAVCNFSM6AAAAABFSC2Q26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSGYZDGMJRGU . You are receiving this because you were assigned.Message ID: @.***>
Ah! Okay, thanks. Good catch, then. How novel, catching a bug before it causes a problem! :)
On Tue, Apr 2, 2024 at 1:36 PM Joseph D. Cohen @.***> wrote:
It didn't find it because there's not yet any such broken reference. There's no Project whose Location was merged after the Project was created. (There are only 7 Project's with a non-nil location.)
On Tue, Apr 2, 2024 at 10:22 AM Jason Hollinger @.***> wrote:
Thanks, Joe. Interesting that check_for_broken_references didn't find that. Every association should look like "belongs to" somewhere. Many-to-many has to have a glue table, each of whose records will "belong to" both of the original tables, for example. And so on. So why wasn't check_for_broken_references picking up that association and therefore noticing the broken reference between project and the missing location?
On Tue, Apr 2, 2024 at 11:30 AM Joseph D. Cohen @.***> wrote:
It's also fails to update Projects, leaving a broken reference there. Perhaps need some meta-programming/reflection in tests to assure that:
- There's fixture for each class that could be affected by a location merger
- The fixture's location changes.
— Reply to this email directly, view it on GitHub <
https://github.com/MushroomObserver/mushroom-observer/issues/2084#issuecomment-2032372926>,
or unsubscribe <
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub < https://github.com/MushroomObserver/mushroom-observer/issues/2084#issuecomment-2032623115>,
or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAALDFDVP7J7AFXZBQLGJW3Y3LSMRAVCNFSM6AAAAABFSC2Q26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSGYZDGMJRGU>
. You are receiving this because you were assigned.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/MushroomObserver/mushroom-observer/issues/2084#issuecomment-2032659798, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYTNNMP3J6BSOQK6SQKEU3Y3LUDFAVCNFSM6AAAAABFSC2Q26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSGY2TSNZZHA . You are receiving this because you commented.Message ID: @.***>
Location#merge
fails to updateherbarium.location_id
. That causes a broken reference for any Herbarium which used the merged Location.Tasks
id
of the non-surviving Location in the admin note which is added to Location.notes