Hey,
From my understanding it's recommended that the business logic does not
commit the session and that the application itself handles the session
lifecycle. Following that, I have all the session handling logic in my
controllers so the business logic just changes the objects as necessary
HI
I have following code,
@db_error_handler
def execute_query(self, query_str, data=None):
'''Execute DB query and retry for common DB interaction errors'''
errors_concerned = [1213, 1205, 2013, 2006]
attempts = 1
while(True):
try:
Hi Alex,
I have a similar use case, and fixed it by buffering the signals until the
session transaction completes. On rollback, the buffered signals are
discarded; on successful commit, the signals are truly emitted.
Cheers,
Jason
On Mon, Sep 22, 2014 at 2:20 AM, Alex Michael
On Sep 22, 2014, at 12:14 PM, Milind Vaidya kava...@gmail.com wrote:
HI
I have following code,
@db_error_handler
def execute_query(self, query_str, data=None):
'''Execute DB query and retry for common DB interaction errors'''
errors_concerned = [1213,
Thanks for the response Michael.
If you're interested, a follow-up question.
http://stackoverflow.com/questions/25979620/sqlalchemy-join-expressions-without-nesting
On Friday, September 19, 2014 10:21:05 AM UTC-4, Michael Bayer wrote:
its at the bottom but i didn’t go through the effort
there's no magic on that one, you'd need to probably write some routine that
digs into each select() and does what you need, looking at stmt._whereclause
and whatever else you want to pull from each one and then build up a new
select() that does what you want. The introspection of a Select
My current solution is to rely on `replace_selectable` but it's not
particularly robust.
On Mon, Sep 22, 2014 at 1:30 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
there’s no magic on that one, you’d need to probably write some routine
that digs into each select() and does what you need,
this is probably already apparent but if I had this sort of problem, I'd more
be asking why do I have this problem in the first place, that is, my program
has made these two SELECT objects that need to be combined, they instead should
be making two data criteria objects of some kind that can be
is it true of sqlalchemy verison 0.7 (which BTW I am using)?
If I close() explicitly only for insert queries, I can see that parallel
inserts happening equal to no. of threads that I have, but if I remove it,
no parallel inserts happen(I am checking this by using show processlist on
mysql
Hrm, that's an interesting thought. Any interest in a real-time
conversation?
This work is for Blaze http://blaze.pydata.org/docs/latest/index.html btw.
I'm lowering a relational algebra abstraction to a variety of other systems
(pandas, spark, python, sqlalchemy, etc...)
On Mon, Sep 22, 2014
On Sep 22, 2014, at 1:40 PM, Milind Vaidya kava...@gmail.com wrote:
is it true of sqlalchemy verison 0.7 (which BTW I am using)?
yes.
from sqlalchemy import *
e = create_engine(mysql://scott:tiger@localhost/test, echo=True)
m = MetaData()
t = Table('t', m, Column('x', Integer,
I mentioned in my earlier post that I am operating in thread safe manner.
In simple words my application is doing following thing,
There are 'n' tracks (some entity in business logic context)
every 5 mins per track have a thread---each thread will spawn 5 threads
per mins-- now each of these
All,
Sorry to resurrect a long-dead thread here, but this seems to have been
left dangling precariously close to becoming productive. ;-)
Seriously, though, there have been a couple
https://groups.google.com/forum/#!searchin/sqlalchemy/security/sqlalchemy/Vl7CvEgVm9c/wK5ljrQ7z4cJ
of
On Sep 22, 2014, at 4:21 PM, Milind Vaidya kava...@gmail.com wrote:
In simple words my application is doing following thing,
There are 'n' tracks (some entity in business logic context)
every 5 mins per track have a thread---each thread will spawn 5 threads per
mins-- now each of these
I put a check in the method to check if the rows are being returned, if so
I am extracting the rows and calling result.close(). For Insert I am
banking on default close() call. Which solved my problem.
On Monday, September 22, 2014 4:39:17 PM UTC-5, Michael Bayer wrote:
On Sep 22, 2014, at
On Monday, September 22, 2014 5:00:26 PM UTC-4, Brian the Lion wrote:
In my scheme, I think there's a role both for silent omission and
error-throwing. For example, getting a list of all managed objects' primary
keys should silently omit objects that the caller doesn't have permission
16 matches
Mail list logo
