Hello.
I occasionally see DetachedInstanceError in apache error log of my web app.
According to
http://docs.sqlalchemy.org/en/rel_0_8/orm/session.html#expunging
an object is detached when:
1. It is expunged.
2. The session is closed.
I use expunge() only in some of my unit tests,
I know this has been discussed a great deal already, but I've been
noticing this:
SomeClass.query()
.filter_by(id = blah)
.execution_options(compiled_cache = _orm_query_cache)
.options(
orm.joinedload(blah),
orm.joinedload(blah, bleh),
orm.joinedload(blah,
What would be great would be to have .sql files and .sqli (mako
templates with some context provided by the env.py) in addition to .py
files. How hard could that be? ;-)
UHHH Alembic *doesn't* support this?! Are you kidding me? Fuckit, I'm
sticking to sqlalchemy-migrate.
--
You
Hello.
Sorry for the long delay. I finally had enough time to produce a minimal
self-contained regression. The attached file produces the following SQL:
WITH RECURSIVE
q_cte(partner_id, max_depth) AS (
SELECT
partner.id AS partner_id,
1 AS max_depth
FROM partner
WHERE
On May 30, 2013, at 7:16 AM, Ladislav Lenart lenart...@volny.cz wrote:
Hello.
I occasionally see DetachedInstanceError in apache error log of my web app.
According to
http://docs.sqlalchemy.org/en/rel_0_8/orm/session.html#expunging
an object is detached when:
1. It is
On May 30, 2013, at 11:25 AM, Claudio Freire klaussfre...@gmail.com wrote:
That way, one could use the second form up there and benefit from
query hashing, because session/param binding wouldn't change the hash,
and it would be a cache hit. Has it been explored already? Or maybe
there's
I think I did not get it.
2013/5/30 Colleen Ross cr...@yapta.com:
What would be great would be to have .sql files and .sqli (mako
templates with some context provided by the env.py) in addition to .py
files. How hard could that be? ;-)
UHHH Alembic *doesn't* support this?! Are you kidding
On Thu, May 30, 2013 at 2:25 PM, Michael Bayer mike...@zzzcomputing.com wrote:
On May 30, 2013, at 11:25 AM, Claudio Freire klaussfre...@gmail.com wrote:
That way, one could use the second form up there and benefit from
query hashing, because session/param binding wouldn't change the hash,
On May 30, 2013, at 2:28 PM, Claudio Freire klaussfre...@gmail.com wrote:
4. it would have a super crapload of very complete and clean unit tests.
Ehm... I would imagine all the current tests involving Query would
cover most of it. A few more cache-specific tests could be added
surely,
my first 25 seconds of looking at this reveals that if you want to be able to
generate a hash, this has to go all the way down to everything.
query.filter(X == Y) means you need a hash for X == Y too.These hashes are
definitely going to be determined using a traversal scheme for sure:
q
On Thu, May 30, 2013 at 3:45 PM, Michael Bayer mike...@zzzcomputing.com wrote:
On May 30, 2013, at 2:28 PM, Claudio Freire klaussfre...@gmail.com wrote:
4. it would have a super crapload of very complete and clean unit tests.
Ehm... I would imagine all the current tests involving Query
On May 30, 2013, at 2:28 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Thu, May 30, 2013 at 2:25 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
If you want to work on a feature that is actually going to change
SQLAlchemy, (and would that be before or after you finish #2720? :)
On May 30, 2013, at 3:10 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Thu, May 30, 2013 at 3:45 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
On May 30, 2013, at 2:28 PM, Claudio Freire klaussfre...@gmail.com wrote:
4. it would have a super crapload of very complete and
On Thu, May 30, 2013 at 4:19 PM, Michael Bayer mike...@zzzcomputing.com wrote:
In case I'm not clear, this would not be cached if I were to take
id(internals)
query(Blah).filter(blah).join(blah).first()
But I don't care, because that's expensive on its own.
result caching (because we're
a very brief example of this, which if you keep digging in you can see how
tricky it gets (fast), is like:
from sqlalchemy.sql import column, table
t1 = table('t1', column('x'), column('y'))
t2 = table('t1', column('x'), column('y'))
t3 = table('t2', column('p'), column('r'))
t4 =
We use func.count().over() in order to help support result pagination.
When attempting to limit the result set, I have found that if other tables
are being joined (for the where clause, but not selected), then I need to
add DISTINCT to the query or else the Cartesian result of my query messes
On May 30, 2013, at 5:19 PM, Kent jkentbo...@gmail.com wrote:
Solution A:
Group by all columns (yielding the same effect as distinct), but which
makes the window analytical function process after the group by and yields
the correct count (17 instead of 72):
are all
my next thought is, if something isn't distinctly hashable, then it should
cancel being hashable entirely. this patch shows it using a symbol
unhashable: https://gist.github.com/zzzeek/5681612 . If any construct has
an unhashable inside of it, then that construct is unhashable too.
The
Thank you, I'll try that, but quick concern: I specifically skipped
trying to use .subquery() because the docs say Eager JOIN generation
within the query is disabled.
Doesn't that mean I won't get my joinedload() results from the inner query?
Or does that refer to the outer query having
On May 30, 2013, at 6:06 PM, Kent jkentbo...@gmail.com wrote:
Thank you, I'll try that, but quick concern: I specifically skipped trying
to use .subquery() because the docs say Eager JOIN generation within the
query is disabled.
Doesn't that mean I won't get my joinedload() results from
this is very helpful because you are here running into an older feature that I
think is not very applicable to modern usage, not to mention not terrifically
documented, so I've added
http://www.sqlalchemy.org/trac/attachment/ticket/2736/ to address changing the
role of select_from() to be more
21 matches
Mail list logo
