You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix event/catalogue membership ORM bugs and bump 0.5.0 → 0.5.1
Two bugs surfaced when tscat_gui (and SciQLop, via the tscat_gui driver)
moved to 0.5.0 — both visible as ValueError raised from
Backend.{add,remove}_events_to_catalogue:
* remove_events_from_catalogue compared membership by Python id() instead
of the SQL primary key. Any caller that resolved an Event via
get_events(uuid=...) (the new fast path that returns wrappers backed
by _LazyBackendEntity) ended up with a different Python instance from
the one stored in catalogue.events and got "Event is not in catalogue."
Fixed by comparing on e.id, matching add_events_to_catalogue.
* After event.remove(permanently=True), catalogue.events kept the
deleted ORM Event in the in-memory collection. A subsequent
add_events_to_catalogue() with a freshly-created Event reusing the
same UUID then hit the existing-id check and was rejected, even
though tscat.get_events(catalogue) reported the catalogue empty.
Backend.remove now detaches an Event from every catalogue.events
collection that holds it before session.delete().
The fast-path query also let _LazyBackendEntity proxies leak into
SQLAlchemy relationships (catalogue.events.extend), which the membership
fix would still trip over later. Added a _resolve_be helper in base.py
and used it at the wrapper→backend boundary for add/remove_events_to_catalogue
and _BackendBasedEntity.remove so SQLAlchemy only ever sees identity-mapped
ORM entities.
Two regression tests cover both scenarios.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
0 commit comments