* Implement optimized batch rule application
- Add apply_all_album_rules/1 to batch apply all album rules in single query
- Add apply_all_artist_rules/1 to batch apply all artist rules in single query
- Update apply_all_rules/0 to use new batch functions
- Add comprehensive tests for batch application
- Use CASE statement in SQL to apply multiple rules efficiently
Co-authored-by: cloud8421 <537608+cloud8421@users.noreply.github.com>
* Add batch application support for track-filtered rules
- Extend apply_all_album_rules/2 to support filtering by tracks
- Extend apply_all_artist_rules/2 to support filtering by tracks
- Update apply_all_rules/1 to use batch functions for track-filtered application
- Remove duplicate function definitions
- Ensures both main use cases (all tracks and specific tracks) are optimized
Co-authored-by: cloud8421 <537608+cloud8421@users.noreply.github.com>
* Add comprehensive documentation for optimization
- Document the problem and solution approach
- Explain SQL generation and performance impact
- Detail trade-offs and backward compatibility
- Include future considerations and scalability notes
Co-authored-by: cloud8421 <537608+cloud8421@users.noreply.github.com>
* Apply credo suggestions and format
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: cloud8421 <537608+cloud8421@users.noreply.github.com>
Co-authored-by: Claudio Ortolina <cloud8421@gmail.com>
When inserting twice, the second insertion is a no-op, due to the fact
that we use `on_conflict: :nothing` in the `Repo.insert/2` call.
This means that for fields generated client side like timestamps we
don't get the stored values, but the client side values (which haven't
been persisted).
In case of the test crossing the second boundary, the second asset would
be different because of the timestamps, and the test would fail.
This test is better. It tests that no matter how many times we insert
the same thing we always have one stored.
Claudio Ortolina