On 25/04/2013 15:04, Michael Bayer wrote:
the columns come out in order because they have a creation order counter
running that tracks the order in which each object was created.There's nothing like
that built into @declared_attr,
I think declared_attr is a bit of a red herring here,
Hi Michael,
Sorry to be a pain, but will these patches be applied to 7.10?
My app needs a lot of mods for it to work in 8.0.
If not don't worry, I guess it is time for me to move on to 8.
I'll try it out this weekend.
Thanks
On Friday, April 26, 2013 8:33:45 AM UTC+10, Michael Bayer wrote:
thank you michael, very helpful points.
in the end i'll just use PostgreSQL native schema since i'm not able to get
the multi-connection thing working. for that i use a common ``
DeclarativeBase`` and ``__table_args__ = {'schema': 'market'}`` or
``__table_args__
= {'schema': 'site'}``.
i'm
Hello.
I have found this recipe:
http://www.sqlalchemy.org/trac/wiki/UsageRecipes/WindowedRangeQuery
I think it fits perfectly for my usecase: process potentially large result set
of ORM instances in chunks of predefined size to limit memory consumption.
I have few questions / remarks:
* I
No, the comma is supposed to be there; it's for tuple unpacking. The
iterable q yields tuples (which in this case are of length one, because the
resultset has only one column).
The column should be whatever attribute of the ORM instances you want to
sort by, not necessarily the primary key.
The
Hello.
I think I understand it all now.
Thank you,
Ladislav Lenart
On 26.4.2013 13:22, Gunnlaugur Thor Briem wrote:
No, the comma is supposed to be there; it's for tuple unpacking. The iterable
q
yields tuples (which in this case are of length one, because the resultset has
only one
Hi Michael Bayer,
Is there any way to dynamically change Transaction Isolation Level ??
I want to do it only for a particular operation. So I can't set it at
Engine or Connection Level, right ??
I am using turbogears + Sqlalchemy with default isolation_level.
What is the default
the patch takes advantage of other improvements in 0.8 and would be
destabilizing for 0.7. it's a pretty major rethink of how join() works.
On Apr 26, 2013, at 4:58 AM, gvv gvver...@gmail.com wrote:
Hi Michael,
Sorry to be a pain, but will these patches be applied to 7.10?
My app needs a
you can make a Session like this:
conn = engine.connect().execution_options(isolation_level='SERIALIZABLE')
session = Session(bind=conn)
# work with session
session.commit()
isolation level is per-transaction.
the default is not set by SQLAlchemy it depends on how your database is
On Apr 26, 2013, at 5:46 AM, Andi Blake andi.ba...@googlemail.com wrote:
i'm still interested in the solution of
http://docs.sqlalchemy.org/en/rel_0_7/orm/session.html#simple-vertical-partitioning
since it toke me some time and i don't like having such an open issue ;)
this is my original
so not to load too much into memory I should do something like:
for i in session.query(someobject).filter(idsomething)
print i
I'm guessing the answer is no, because of the nature of sql, but I'm not an
expert so I'm asking.
Thanks for the help!
--
You received this message because you
Read the source:
def all(self):
Return the results represented by this ``Query`` as a list.
This results in an execution of the underlying query.
return list(self)
it means that this method collects everything it needs and it is yielded by
the generator.
If you returns the
Query object has a __iter__ descriptor.
2013/4/26 Mauricio de Abreu Antunes mauricio.abr...@gmail.com
Read the source:
def all(self):
Return the results represented by this ``Query`` as a list.
This results in an execution of the underlying query.
return list(self)
Hi,
On 26/04/2013 16:41, alonn wrote:
so not to load too much into memory I should do something like:
for i in session.query(someobject).filter(idsomething)
print i
I'm guessing the answer is no, because of the nature of sql, but I'm
not an expert so I'm asking.
yes you can, check out
On Fri, Apr 26, 2013 at 12:06 PM, Werner werner.bru...@sfr.fr wrote:
On 26/04/2013 16:41, alonn wrote:
so not to load too much into memory I should do something like:
for i in session.query(someobject).filter(idsomething)
print i
I'm guessing the answer is no, because of the nature of
On 26/04/2013 17:07, Claudio Freire wrote:
On Fri, Apr 26, 2013 at 12:06 PM, Werner werner.bru...@sfr.fr wrote:
On 26/04/2013 16:41, alonn wrote:
so not to load too much into memory I should do something like:
for i in session.query(someobject).filter(idsomething)
print i
I'm guessing
On Fri, Apr 26, 2013 at 12:24 PM, Werner werner.bru...@sfr.fr wrote:
On 26/04/2013 17:07, Claudio Freire wrote:
On Fri, Apr 26, 2013 at 12:06 PM, Werner werner.bru...@sfr.fr wrote:
http://sqlalchemy.readthedocs.org/en/rel_0_8/orm/tutorial.html#querying
Not entirely, if you don't use
On Apr 26, 2013, at 12:24 PM, Claudio Freire klaussfre...@gmail.com wrote:
Um... a tad OT, but looking at that code, there's lots of
opportunities for optimization.
I'll have to profile a bit and let you know.
are you referring to sqlalchemy/orm/loading.py ? I'd be pretty impressed if
On Fri, Apr 26, 2013 at 1:35 PM, Michael Bayer mike...@zzzcomputing.com wrote:
Um... a tad OT, but looking at that code, there's lots of
opportunities for optimization.
I'll have to profile a bit and let you know.
are you referring to sqlalchemy/orm/loading.py ? I'd be pretty impressed if
Mike, this is interesting stuff.
Let's say I use isolation_level as serializabe. Is there a counterpart
in performance? If yes, is there something I can do to counter weight?
ie. bigger connection pool, stream_results (psycopg), etc.
Cheers,
Richard.
On 04/26/2013 11:02 AM, Michael Bayer
On Apr 26, 2013, at 12:41 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Fri, Apr 26, 2013 at 1:35 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
Um... a tad OT, but looking at that code, there's lots of
opportunities for optimization.
I'll have to profile a bit and let you
serializable will reduce performance, yes. There's not much way around it,
though the tradeoffs vary greatly depending on database. Postgresql for example
introduces fairly minimal overhead versus repeatable read (see
http://www.postgresql.org/docs/9.1/static/transaction-iso.html) since
Thanks again Mike. One more motive to stick to Postgres :)
Cheers,
Richard.
On 04/26/2013 02:11 PM, Michael Bayer wrote:
serializable will reduce performance, yes. There's not much way
around it, though the tradeoffs vary greatly depending on database.
Postgresql for example introduces
Hey Mike!
I'm almost there :) The only problem now is with a column that returns a
postgres *ARRAY* type.
When labeling is not applied, I get the same error as before:
*sqlalchemy.exc.NoSuchColumnError: Could not locate column in row for
column 'connect_path'*
But, when I apply a label on
Ha! A little google search and ...
https://groups.google.com/forum/?fromgroups=#!topic/sqlalchemy/FHuCN-X9L8A
https://groups.google.com/forum/?fromgroups=#%21topic/sqlalchemy/FHuCN-X9L8A
Voilà!
:-)
Kind regards,
Richard.
On 04/26/2013 03:50 PM, Richard Gerd Kuesters wrote:
Hey Mike!
I'm
is that 0.8? that particular issue should have been fixed.
On Apr 26, 2013, at 2:50 PM, Richard Gerd Kuesters rich...@humantech.com.br
wrote:
Hey Mike!
I'm almost there :) The only problem now is with a column that returns a
postgres ARRAY type.
When labeling is not applied, I get
I'm still fairly new at sqlalchemy, and am still occasionally being
surprised by how sometimes-too-clever it is. I ran into one of those
moments today.
I have something that looks like this. (All the tables are reflected.)
class Parent(Model, SimpleLookupTable):
__table__ =
On Friday, April 26, 2013 12:25:42 AM UTC+2, Michael Bayer wrote:
this will work out of the box in 0.8 as auto-correlation has been improved
a lot. in 0.7 you can add correlate() explicitly:
Nice, many thanks :)
--
You received this message because you are subscribed to the Google
On Fri, Apr 26, 2013 at 2:04 PM, Michael Bayer mike...@zzzcomputing.com wrote:
are you referring to sqlalchemy/orm/loading.py ? I'd be pretty impressed
if you can find significant optimizations there which don't break usage
contracts.I've spent years poring over profiles and squeezing
Given
class Person:
id
class Topic:
id
class Person2Topic :
id
topic_id - fkeys topic(id)
person_id - fkeys person(id)
class Message:
id
person_id_author - fkeys person(id)
topic_id - fkeys topic(id)
I wanted to select by joining the Person2Topic table directly, with a
filter
query(
On Apr 26, 2013, at 6:13 PM, Claudio Freire klaussfre...@gmail.com wrote:
Ultimately, though, it's InstrumentedAttribute.__get__ the one sucking
up 30% of alchemy-bound CPU time. I guess there's little that can be
done, since it's necessary to track state changes. But there's a neat
property
On Apr 26, 2013, at 7:10 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
Given
class Person:
id
class Topic:
id
class Person2Topic :
id
topic_id - fkeys topic(id)
On Apr 26, 2013, at 4:01 PM, Daniel Grace thisgenericn...@gmail.com wrote:
I'm still fairly new at sqlalchemy, and am still occasionally being surprised
by how sometimes-too-clever it is. I ran into one of those moments today.
I have something that looks like this. (All the tables are
I thought it should work too, but I'm getting:
InvalidRequestError: Could not find a FROM clause to join from. Tried
joining to class 'app.models.Person2Topic', but got: Can't find any
foreign key relationships between 'message' and 'person_2_topic'.
If i have time this weekend I'll look
On Fri, Apr 26, 2013 at 8:15 PM, Michael Bayer mike...@zzzcomputing.com wrote:
Anyway, with that (fragile) change, I get a speedup of 10% overall
runtime, and about 50% alchemy-specific runtime. Considering I knew
about attribute access' slowness and avoided it in my test, that has
to account
On Fri, Apr 26, 2013 at 8:47 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Fri, Apr 26, 2013 at 8:15 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
Anyway, with that (fragile) change, I get a speedup of 10% overall
runtime, and about 50% alchemy-specific runtime. Considering I knew
well you example here seems like it's not literal, do you mean to use and_() ?
I see a tuple there and an assignment. It shouldn't be trying to do an
auto-join like that so it seems like join() isn't being called correctly.
On Apr 26, 2013, at 7:42 PM, Jonathan Vanasco jonat...@findmeon.com
On Apr 26, 2013, at 7:56 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Fri, Apr 26, 2013 at 8:47 PM, Claudio Freire klaussfre...@gmail.com
wrote:
On Fri, Apr 26, 2013 at 8:15 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
Anyway, with that (fragile) change, I get a speedup of
On Apr 26, 2013, at 7:59 PM, Michael Bayer mike...@zzzcomputing.com wrote:
On Apr 26, 2013, at 7:56 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Fri, Apr 26, 2013 at 8:47 PM, Claudio Freire klaussfre...@gmail.com
wrote:
On Fri, Apr 26, 2013 at 8:15 PM, Michael Bayer
On Fri, Apr 26, 2013 at 9:01 PM, Michael Bayer mike...@zzzcomputing.com wrote:
All attributes have to be expire-able and act as proxies for a database
connection so I'm not really sure where to go with that.I'm not too
thrilled about proposals to build in various alternate performance
Everytime I code SQLAlchemy relationships I note that insert operation like
this (tutorial) does not need commit()
http://docs.sqlalchemy.org/en/latest/orm/tutorial.html#working-with-related-objects
When using this bidirectional relationship() is the data automatically
commited to the dabase?
Being more specific I talk about this part:
jack = User('jack', 'Jack Bean', 'gjffdd') jack.addresses[]
jack.addresses = [...
Address(email_address='j...@google.com'),...
Address(email_address='j...@yahoo.com')]
Are addresses automaticamente added and
I think I'm answering myself:
address = Address(args) # passing jack's id
session.add(address)
session.commit()
2013/4/27 Mauricio de Abreu Antunes mauricio.abr...@gmail.com
Being more specific I talk about this part:
jack = User('jack', 'Jack Bean', 'gjffdd') jack.addresses[]
43 matches
Mail list logo
