| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
for setting up baked lazy loaders would interfere with other
loader strategies that rely on lazy loading as a fallback, e.g.
joined and subquery eager loaders, leading to ``IndexError``
exceptions at mapper configuration time.
fixes #3612
|
| |
|
|
|
|
|
|
|
| |
directly or within lazy loads, didn't consider the mapper's "get clause"
as part of the cache key, causing bound parameter mismatches if the
clause got re-generated. This clause is cached by mappers
on the fly but in highly concurrent scenarios may be generated more
than once when first accessed.
fixes #3597
|
| |
|
| |
Thanks to Mike Bayer for suggesting a simpler refactoring.
|
| |
|
| |
Also add a couple of missing tests.
|
| |
|
|
| |
- changelog / version note finishing
|
| |
|
|
| |
- alter the approach so that the initial callable is working just like add_criteria/with_criteria
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When making baked query in classmethod of declarative base,
cls should be added in cache key.
@as_declarative
class Base(object):
@classmethod
def baked_query(cls):
return bakery(lambda: session.query(cls), (cls,))
|
|
|
simple but unusual system allows for a dramatic savings in Python
overhead for the construction and processing of orm :class:`.Query`
objects, from query construction up through rendering of a string
SQL statement.
fixes #3054
|
