Am 13.06.2013, 00:42 Uhr, schrieb Andy aml...@gmail.com:
Ah, okay. I think I understand what I was missing initially. I've had
another go at this and it seems to work as required, even on MySQL. Not
sure how this all works with SQLAlchemy but I would expect it to be fine
with it.
insert into
Hey Michael,
thanks for your fast response and especially the recipe. I completely
forgot the FAQ. Most of my questions are usually covered by the
documentation, and search engines seem to prefer StackOverflow et al.
On Mi, 2013-06-12 at 16:15 -0400, Michael Bayer wrote:
This is the FAQ entry
Hello.
I have a query that does a full scan of an inherited table with more than
million rows even though I need only 100 of them (on postgres 9.1). This is a
real bummer! Please help me rewrite the SA query or instruct postgres to not do
this stupidity.
I have the following setup (only the
Hi all,
Based on some comments here and in the SqlAlchemy IRC chat room, I've
updated my decorator to make some changes. Here is the updated version:
class ScopedSession(object):
SESSIONMAKER = None # this is the single sessionmaker instance
def __init__(self, engine,
Please try out 0.9 from the git master which fixes the issue of the nested
SELECT on the right side of a join.
Sent from my iPhone
On Jun 13, 2013, at 9:18 AM, Ladislav Lenart lenart...@volny.cz wrote:
Hello.
I have a query that does a full scan of an inherited table with more than
I'm glad you got a better solution. The key is now test it and see if
memory leaks and connections get closed properly.
The main problem in Twisted, IMHO, is the usage of maybeDeferred in
some points, which can go to a thread or stay in the main thread, which
is a little hard to predict and
Unfortunately migrating to SA 0.9 is not an option for me at the moment due to
severe time constraints.
Could you please help me write SA query for 0.7.9 that uses index scan and also
loads all the necessary relations? It must be possible with a proper use of
from_statement(), contains_eager()
Hello.
Just a minor correction:
The new query can return whatever it pleases as long as it *also*
returns Foo instances with properly populated relations.
The rest of the e-mail is the same.
Please help me,
Ladislav Lenart
On 13.6.2013 17:03, Ladislav Lenart wrote:
Unfortunately
HI!
I implemented a TypeDecorator which allows setting the precision of a
datetime value.
It does something like:
*import datetime*
*
*
*class PrecisionDateTime(TypeDecorator):*
*def process_bind_param(self, value, dialect):*
*return datetime.datetime(value.year, value.month,*
*
On Jun 13, 2013, at 11:03 AM, Ladislav Lenart lenart...@volny.cz wrote:
Unfortunately migrating to SA 0.9 is not an option for me at the moment due to
severe time constraints.
I was pretty sure you'd say that, though I'm really looking to verify that my
fixes are going to hold up under real
HI!
I implemented a TypeDecorator which allows setting the precision of a
datetime value.
It does something like:
*import datetime*
*
*
*class PrecisionDateTime(TypeDecorator):*
*def process_bind_param(self, value, dialect):*
*return datetime.datetime(value.year,
On Thursday, June 13, 2013 1:59:16 AM UTC-7, Charlie Clark wrote:
Am 13.06.2013, 00:42 Uhr, schrieb Andy aml...@gmail.com javascript::
Ah, okay. I think I understand what I was missing initially. I've had
another go at this and it seems to work as required, even on MySQL.
Not
sure
Am 13.06.2013, 21:20 Uhr, schrieb Andy aml...@gmail.com:
It's the original issue. The relation (that I want the ORM to see) isn't
what's literally set in the schema by foreign keys, and the
primaryjoin/foreign_keys ORM magic for this IMO sucks. Something like
onetomany and manytoone in the
13 matches
Mail list logo
