summaryrefslogtreecommitdiff
path: root/examples/sharding
diff options
context:
space:
mode:
authorMike Bayer <mike_mp@zzzcomputing.com>2019-12-09 18:05:00 -0500
committerMike Bayer <mike_mp@zzzcomputing.com>2019-12-22 11:31:13 -0500
commit60e7034a7423955cd89d5624f8769d3804ca6d82 (patch)
tree027fd963fc073970b9ab62ae7f389e61192b1992 /examples/sharding
parentc6554ac52bfb7ce9ecd30ec777ce90adfe7861d2 (diff)
downloadsqlalchemy-60e7034a7423955cd89d5624f8769d3804ca6d82.tar.gz
Use expanding IN for all literal value IN expressions
The "expanding IN" feature, which generates IN expressions at query execution time which are based on the particular parameters associated with the statement execution, is now used for all IN expressions made against lists of literal values. This allows IN expressions to be fully cacheable independently of the list of values being passed, and also includes support for empty lists. For any scenario where the IN expression contains non-literal SQL expressions, the old behavior of pre-rendering for each position in the IN is maintained. The change also completes support for expanding IN with tuples, where previously type-specific bind processors weren't taking effect. As part of this change, a more explicit separation between "literal execute" and "post compile" bound parameters is being made; as the "ansi bind rules" feature is rendering bound parameters inline, as we now support "postcompile" generically, these should be used here, however we have to render literal values at execution time even for "expanding" parameters. new test fixtures etc. are added to assert everything goes to the right place. Fixes: #4645 Change-Id: Iaa2b7bfbfaaf5b80799ee17c9b8507293cba6ed1
Diffstat (limited to 'examples/sharding')
-rw-r--r--examples/sharding/attribute_shard.py20
1 files changed, 2 insertions, 18 deletions
diff --git a/examples/sharding/attribute_shard.py b/examples/sharding/attribute_shard.py
index 608f0f9c3..7b8f87d90 100644
--- a/examples/sharding/attribute_shard.py
+++ b/examples/sharding/attribute_shard.py
@@ -17,11 +17,8 @@ from sqlalchemy.sql import operators
from sqlalchemy.sql import visitors
-# db1 is used for id generation. The "pool_threadlocal"
-# causes the id_generator() to use the same connection as that
-# of an ongoing transaction within db1.
echo = True
-db1 = create_engine("sqlite://", echo=echo, pool_threadlocal=True)
+db1 = create_engine("sqlite://", echo=echo)
db2 = create_engine("sqlite://", echo=echo)
db3 = create_engine("sqlite://", echo=echo)
db4 = create_engine("sqlite://", echo=echo)
@@ -220,20 +217,7 @@ def _get_query_comparisons(query):
clauses.add(column)
def visit_binary(binary):
- # special handling for "col IN (params)"
- if (
- binary.left in clauses
- and binary.operator == operators.in_op
- and hasattr(binary.right, "clauses")
- ):
- comparisons.append(
- (
- binary.left,
- binary.operator,
- tuple(binds[bind] for bind in binary.right.clauses),
- )
- )
- elif binary.left in clauses and binary.right in binds:
+ if binary.left in clauses and binary.right in binds:
comparisons.append(
(binary.left, binary.operator, binds[binary.right])
)