Skip to content

Unify filter condition builders and handler code paths #136

Description

@seapagan

Summary

The query filtering code currently has two parallel implementations for condition construction:

  • handler path: _handle_equality, _handle_in, _handle_like, _handle_comparison
  • builder path: _build_sql_condition, _build_in_condition, _build_like_condition

This duplicates operator/type validation and SQL fragment rules, which increases drift risk over time.

Goal

Refactor filter handling so operator/type validation and SQL fragment construction are centralized in the _build_* condition functions, while preserving existing behavior.

Scope

  • Refactor handler methods to delegate to builder functions
  • Keep existing self.filters contract intact (or migrate in a fully consistent way)
  • Preserve exact:
    • exception types and messages
    • SQL clause semantics
    • parameter ordering
    • NULL and COLLATE NOCASE behavior
  • Update/add tests to prevent behavior drift

Non-goals

  • No new filter operators
  • No public API changes
  • No query planner/performance rewrites outside this refactor

Acceptance Criteria

  • Existing filter tests pass unchanged (or with only necessary structural updates)
  • Added regression tests for:
    • __eq, __isnull, __notnull
    • __in, __not_in
    • __like, __startswith, __endswith, __contains, case-insensitive variants
    • comparison operators
    • type validation error parity
  • Output SQL fragments/params remain behaviorally equivalent across code paths

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions