Thanks Peter for your answer.
On 11 juin, 16:16, Peter Hansen [EMAIL PROTECTED] wrote:
Aside from that, you don't have many options. What about changing the
query so that it will return its results in increments, rather than all
at once? If it's a long-running query but you can break it up
Hi.
I want to have two Table definitions in one MetaData which are the
same except the name of the second one has SND_ prefix. To avoid
duplication of schema definition I looked at Table.tometadata() source
and created the following function:
def _cloneToSND(table, metadata):
return
Michael Bayer wrote:
The most crucial, although not the issue in this specific example, is
that the relations table is used both as the secondary table in a
relation(), and is also mapped directly to the Relation class. SQLA
does not track this fact and even in a working mapping will
Hi All,
I am seeing something I didn't expect using in_.
Here is a simple example, exactly as I expect:
In [13]: col = Trade.c.TradeId.in_([1,2])
In [14]: sel = select([col])
In [15]: print col
Trade.TradeId IN (?, ?)
In [16]: print sel
SELECT Trade.TradeId IN (?, ?) AS anon_1
FROM Trade
On Jun 12, 2008, at 4:05 AM, Artur Siekielski wrote:
Hi.
I want to have two Table definitions in one MetaData which are the
same except the name of the second one has SND_ prefix. To avoid
duplication of schema definition I looked at Table.tometadata() source
and created the following
On Jun 12, 2008, at 4:48 AM, Malthe Borch wrote:
Certainly stable is good; strictly looking at FKs only might
ultimately
make for a simpler implementation though.
It starts out as simpler, but that simplicity breaks down almost
immediately as the dependency rules, which include rules
this is ticket #1074. A slightly klunky workaround for now is:
col = t1.c.c1.in_([select([t1.c.c1]).as_scalar()])
On Jun 12, 2008, at 10:04 AM, casbon wrote:
Hi All,
I am seeing something I didn't expect using in_.
Here is a simple example, exactly as I expect:
In [13]: col =
Ah, thanks.
Should have searched the bug reports as well as the list.
On Jun 12, 3:27 pm, Michael Bayer [EMAIL PROTECTED] wrote:
this is ticket #1074. A slightly klunky workaround for now is:
col = t1.c.c1.in_([select([t1.c.c1]).as_scalar()])
On Jun 12, 2008, at 10:04 AM, casbon wrote:
On Jun 12, 2008, at 10:51 AM, casbon wrote:
Ah, thanks.
Should have searched the bug reports as well as the list.
no no, I just created that ticket :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
On Apr 16, 2008, at 3:55 PM, mg wrote:
I have a couple of threads that are working on the same objects,
passing them back and forth in queues. I have just started testing
with the Sqlalchemy parts turned on, and I am getting the already
attached to session message. Also of note is that I
In the following code, I am using django templates to render data from a
SQLAlchemy-mapped database. I subclass django.template.Context, so that
I can pass it a unique ID, from which it determines what to pull from
the DB. But when it comes time to render the template (that is: when I
actually
SohpContext creates a Session, then loses it immediately. That's your
transactional context getting thrown away basically. You should have
a Session open for the lifespan of all ORM operations which includes
lazy loads. See
Greeting Alchemists,
in order to implement schema diffing, it would be nice if two similar
ColumnDefault objects would be comparable as such. I attach a path to
implement such test. Would it make sense to add this support in
Alchemy's core or should a schema diffing library add it through
Michael Bayer [EMAIL PROTECTED] writes:
can't the schema diff utility include a function such as
compare_defaults(a, b) ? a ColumnDefault isn't really like a SQL
expression object so the __eq__()/__ne__() seems inappropriate (in
general, overriding __eq__() is an endeavor to be taken
The first release of 0.5 is now available. For those who have been
slow to move to the trunk, 0.5 represents a great leap in refinement
to the paradigms that have become standard in 0.4, with a good degree
of API lockdown that removes all the clutter that was lingering from
0.3.
For the
On Jun 12, 2008, at 5:01 PM, Yannick Gingras wrote:
Michael Bayer [EMAIL PROTECTED] writes:
can't the schema diff utility include a function such as
compare_defaults(a, b) ? a ColumnDefault isn't really like a SQL
expression object so the __eq__()/__ne__() seems inappropriate (in
judging by the slapdown in this ticket, and it looks safe to say that
this behavior in SQLite will never change:
http://www.sqlite.org/cvstrac/tktview?tn=2553 backend of
Yow - that is a pretty terse slapdown! It doesn't seem like sqlite
will ever support it.
I keep hoping that sqlalchemy
17 matches
Mail list logo
