Skip to content

Allow mixing DataFrameSource and PinSource in multi-table sessions #256

Description

@cpsievert

Currently check_source_compatibility uses a class-identity check (type(new) is not type(first)) that blocks natural blends of source types. In practice, DataFrameSource and PinSource both materialize an eager frame at construction and could share a single DuckDBExecutor — the identity check is the only thing stopping it.

What to change

  • Loosen check_source_compatibility to group by capability (can this source produce an eager frame for DuckDB registration?) rather than exact class identity
  • Broaden DuckDBExecutor.__init__ to accept any source that satisfies this contract, not just DataFrameSource
  • Update the routing in _build_query_executor accordingly

Out of scope

Remote-source coalescing (SQLAlchemy/Ibis into a shared DuckDB via snapshot or live ATTACH) is explicitly deferred — snapshot mode requires full table materialization at startup which doesn't scale, and live attach introduces SQL dialect drift, lockdown relaxation, and per-dialect connection-string translation. This issue covers local materializable sources only.

Context

Identified during review of #195.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions