On Wed, 2012-12-05 at 17:16:01 -0800, Hong Minhee wrote:
But for work in works: work.like_query.count() causes inefficient 1+N
queries even if we have the right indices for it. Of course I could query
like session.query(Work, count()).join(Work.like_set).group_by(Work) but
it’s somewhat
Hello,
Any idea why the following doesn't work ? :
Topic2= orm.aliased(Topic)
q= Occurrence.query.\
join(Occurrence.datasheet).\
options(orm.contains_eager(Occurrence.datasheet)).\
join(Topic2).\
options(orm.contains_eager(DataSheet.topic,alias=Topic2)).\
cool, thanks a lot for the info, I'll check that.
__
Piensa en el medio ambiente - mantenlo en la pantalla. NO lo imprimas si NO es
necesario.
Think green - keep it on the screen. Do NOT print if it is NOT
On Dec 5, 2012, at 6:50 PM, Derek Harland wrote:
I wonder if a solution here is to somehow allow the schema argument to also
be given as a tuple. eg
schema=x.y would generate a DDL path as x.y
schema=[x.y] would generate a DDL path as [x.y]
schema=[a.b, x.y]
On Dec 6, 2012, at 7:47 AM, Julien Cigar wrote:
Hello,
Any idea why the following doesn't work ? :
Topic2= orm.aliased(Topic)
q= Occurrence.query.\
join(Occurrence.datasheet).\
options(orm.contains_eager(Occurrence.datasheet)).\
join(Topic2).\
In fact the problem is more that, with the following:
http://pastie.org/5489005 I don't know how to tell SQLAlchemy that it
should join the DataSheet relation only once for the query and not once
per join(). One option could be to add a
.options(orm.noload(MyObject.datasheet)) for every mapped
On 12/06/2012 15:45, Michael Bayer wrote:
On Dec 6, 2012, at 7:47 AM, Julien Cigar wrote:
Hello,
Any idea why the following doesn't work ? :
Topic2= orm.aliased(Topic)
q= Occurrence.query.\
join(Occurrence.datasheet).\
options(orm.contains_eager(Occurrence.datasheet)).\
On 12/06/2012 16:02, Julien Cigar wrote:
On 12/06/2012 15:45, Michael Bayer wrote:
On Dec 6, 2012, at 7:47 AM, Julien Cigar wrote:
Hello,
Any idea why the following doesn't work ? :
Topic2= orm.aliased(Topic)
q= Occurrence.query.\
join(Occurrence.datasheet).\
Hi,
I hope everyone's keeping well. It's been ages since I've been on the list.
I do use SQLAlchemy from time to time, but now it generally works so well,
that I don't have any questions to ask!
But I would appreciate some thoughts on the approach I've taken with a
multi-tennant SaaS web app.
On Dec 6, 2012, at 11:14 AM, Julien Cigar wrote:
Another thing I wondered is if there is a shortcut (not joinedload()) for:
Bar.query.join(Foo).options(orm.contains_eager(Bar.foo)).filter(Foo.id==1)
I thought something like:
Bar.query.join(Foo, prop='foo').filter(Foo.id==1)
(to be
On Dec 6, 2012, at 11:59 AM, Paul Johnston wrote:
Hi,
I hope everyone's keeping well. It's been ages since I've been on the list. I
do use SQLAlchemy from time to time, but now it generally works so well, that
I don't have any questions to ask!
But I would appreciate some thoughts on
I use guid primary keys fairly heavily. There is a performance impact due
to the size of the key; you just can't fit as much of the index in memory
as you otherwise could. On the flip side, when you have multiple database
shards, you never need to worry about keys being duplicated, so you can
For case insensitive columns:
MySQL - use utf8_general_ci
SQLite - use NOCASE collation
Can migration tool handle that for most databases or it should be better
done in application code?
Thanks and best regards,
--
You received this message because you are subscribed to the Google
On Dec 6, 2012, at 3:17 PM, junepeach wrote:
For case insensitive columns:
MySQL - use utf8_general_ci
SQLite - use NOCASE collation
Can migration tool handle that for most databases or it should be better done
in application code?
sure:
def character_type(length):
return
Thanks, this is nice, I will use it in my code.
On Thursday, December 6, 2012 3:17:25 PM UTC-5, junepeach wrote:
For case insensitive columns:
MySQL - use utf8_general_ci
SQLite - use NOCASE collation
Can migration tool handle that for most databases or it should be better
done in
I tested my code, and got below:
Traceback (most recent call last):
File /usr/local/bin/alembic, line 9, in module
load_entry_point('alembic==0.4.0', 'console_scripts', 'alembic')()
File /usr/local/lib/python2.7/dist-packages/alembic/config.py, line
255, in main
versionadded is 0.8
On Dec 6, 2012, at 4:36 PM, junepeach wrote:
I tested my code, and got below:
Traceback (most recent call last):
File /usr/local/bin/alembic, line 9, in module
load_entry_point('alembic==0.4.0', 'console_scripts', 'alembic')()
File
Oh, I see, mine is not sqlalchemy 0.8. Thanks.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sqlalchemy/-/dvjzhmyWicoJ.
To post to this group, send email to
How to upgrade to a newer sqlalchemy version? I can not find a related
document. Should I just use pip to install the current one? Will both version
conflict?
Thank you very much for your quick response and help!
JP
--
You received this message because you are subscribed to the Google Groups
19 matches
Mail list logo
