render bind_expression around each literal_execute expanding value
メンテナーはふだん 1 日以内に返信
@chirag-gupta7 がすでに取り組んでいます。
2026年11月6日 から。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 67/100
調査の方向性
Start by tracing _process_parameters_for_postcompile and the expanding parameter element renderers described in the issue, then compare them with the literal_binds compile path. Reproduce the case with TypeDecorator.bind_expression() and the expanding literal_execute parameter. Done means the emitted SQL keeps 'a, b' intact inside its lower() expression and the compile and round trip tests pass.
索引モデルが issue の本文から書いたものです。
説明
Reported by @basavaraj-sm05 in #13730
Description
When an expanding parameter is also marked literal_execute=True and its datatype has a bind_expression(), the values of the IN list are rendered as SQL literals at execution time and joined with ", ", and then _process_parameters_for_postcompile splits that rendered text on ", " again to wrap each piece with the bind expression. That works for bound placeholders, which never contain a comma, but a literal value such as 'a, b' gets torn in half. With a TypeDecorator whose bind_expression is func.lower(...):
stmt = select(t).where(
t.c.name.in_(bindparam("q", expanding=True, literal_execute=True))
)
conn.execute(stmt, {"q": ["a, b", "c"]})
emits
WHERE t.name IN (lower('a), lower(b'), lower('c'))
and the row holding a, b is silently missing from the result (or wrongly kept by a NOT IN). The literal_binds compile path already handled this correctly by applying the template per value before joining, so this change makes the execution path do the same: the templates for expanding parameters are picked up from the compiled string once and passed down to the element renderers, and process_expanding no longer splits rendered text. Bound placeholder rendering comes out identical to before. Compile level and round trip tests are included along with a changelog entry.
- 主要言語
- Python
- スター
- 12.3k
- フォーク
- 1.8k
- 平均マージ
- 2日 10時間
- マージ済み PR(30日)
- 9
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
sqlalchemy/sqlalchemy のほかの issue
-
requires triage
難易度 1/5 1〜3時間 初心者へのやさしさ 85/100
sqlalchemy/sqlalchemy#13784 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
bug engine
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
sqlalchemy/sqlalchemy#13770 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
declared_attr.cascading fails to typecheck under mypy / pyright on documented usage再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンbug orm typing
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
sqlalchemy/sqlalchemy#13731 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
PostgreSQL multihost URL with bracketed IPv6 hosts raises ValueError: too many values to unpack再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンbug engine postgresql
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
sqlalchemy/sqlalchemy#13637 · コメント 6 件 ·
メンテナーはふだん 1 日以内に返信
-
asyncpg dialect raises DBAPIError, not DataError, for SQLSTATE class 22 errors対応中かも @HardMax71 が 21 日前に担当しました。 オープンbug code review in progress dialects
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
sqlalchemy/sqlalchemy#13636 · コメント 19 件 ·
メンテナーはふだん 1 日以内に返信
sqlalchemy/sqlalchemy の issue をすべて見る
似ている issue
-
SslLibrary crashes with unhandled OSError: port/proto not found on non-standard SSL ports対応中かも @himanchalkaushale が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
OWASP/Nettacker#1884 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
A-connection-core C-enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
aws-samples/sample-per-model-bedrock#869 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
fzn0x/watchtower#17 ·