It looks like your sub-select (before the joins) is processing up to
140,015 records, so that will slow things down since the database may
not optimize that sub-selection based upon your outer joins. As a
quick check, try reducing the 140,000 offset to 0 (I know this won't
work for your
If I am just issuing a read-only query, and I want to make sure that
nothing will change in the middle, do I need a transaction? If so,
what do I do with it when I'm done - commit or rollback?
For example, I want to do this:
for user in Session.query(User):
print user.name
Should I use a
On Saturday 07 June 2008 21:35:35 Tomer wrote:
If I am just issuing a read-only query, and I want to make sure
that nothing will change in the middle, do I need a transaction? If
so, what do I do with it when I'm done - commit or rollback?
For example, I want to do this:
for user in
Thanks. What would happen if I didn't do anything (I've seen lots of
examples online that will just issue a query like
Session.query(User).all() and that's all). Will that query start a
transaction if it's a transactional session?
On Jun 7, 11:58 am, [EMAIL PROTECTED] wrote:
On Saturday 07 June
On Saturday 07 June 2008 22:50:36 Tomer wrote:
Thanks. What would happen if I didn't do anything (I've seen lots
of examples online that will just issue a query like
Session.query(User).all() and that's all). Will that query start a
transaction if it's a transactional session?
no idea, never
On Sat, Jun 7, 2008 at 2:50 PM, Tomer [EMAIL PROTECTED] wrote:
Thanks. What would happen if I didn't do anything (I've seen lots of
examples online that will just issue a query like
Session.query(User).all() and that's all). Will that query start a
transaction if it's a transactional
On Jun 7, 2008, at 3:50 PM, Tomer wrote:
Thanks. What would happen if I didn't do anything (I've seen lots of
examples online that will just issue a query like
Session.query(User).all() and that's all). Will that query start a
transaction if it's a transactional session?
when you use the
braydon fuller wrote:
That's the part I don't get is that it shouldn't be empty... I may
have fixed this by using 'try', and then returning 'None' if it fails.
[EMAIL PROTECTED] wrote:
first two mean the result of the query is empty.
On Friday 06 June 2008 01:49:23 braydon fuller wrote:
Thanks for the detailed response.
I have two follow-up questions:
1) From what I understand, if I read an object (eg, Student) from
the database, modify that object or other objects, and then commit, I
have no guarantee that the object didn't change between the time I
read it and the time I
