cf143f70af
Artist detail pages ran check_album_exists_with_editions and check_track_exists per discography item, each firing 5+ title variations times 3 artist variations of fuzzy LIKE searches plus fallback broad-artist queries. For a 30-album artist that was ~450 SQL round-trips just to answer "which of these do I own." Hoist the artist's library albums and tracks into memory once per request via two new helpers — get_candidate_albums_for_artist and get_candidate_tracks_for_albums — and thread them through as optional candidate_albums / candidate_tracks params on check_album_exists_with_editions, check_album_exists_with_completeness, check_track_exists, check_album_completion, and check_single_completion. Batched path scores the same _calculate_album_confidence / _calculate_track_confidence against the in-memory list, preserving Smart Edition Matching and accuracy. Title-only cross-artist fallback still fires for collaborative-album edge cases. None on either param preserves legacy per-item SQL behavior for unaffected callers. Applied to both /api/library/completion-stream (library artist detail page) and iter_artist_discography_completion_events (Artists search page). Timing logs added to confirm the pre-fetch cost and loop elapsed time. On a Kendrick page load, per-album resolution drops from ~8 seconds to under the 50ms streaming sleep floor. Observed ~100x SQL reduction on the happy path. |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| music_database.py | ||