On 10/12/16 3:45 PM, Jonathan Vanasco wrote:

On Wednesday, October 12, 2016 at 5:58:41 PM UTC-4, Alfred Perlstein wrote:

    Oh nice!! Will this be called in the context of the same thread
    executing the sql?  This would allow me to debug without
    formatting all
    debugs I believe...

It depends on how you're using threads and connections. It should/does under most situations. It is entirely possible that you are using things wrong or are abusing the library -- lots of people do that inadvertently (myself included).

Check out the docs on http://docs.sqlalchemy.org/en/latest/orm/contextual.html , and there is also some stuff on threadlocal under pooling.

For stuff like this, I just use the approach that Mike advocated -- just filter the standard python logger. An `.ini` file configures my loggers to print the thread id on the line prefix, and I direct sqlalchemy logging to a dedicated file. Then i just grep that file for a given thread id.

None of the performance issues you raise make much sense to me -- the overhead is negligible and this would all be done on a dev environment. turning something like this on/off on production would worry me about the application design.

Any chance that you coming from another programming language? It sounds like you're unfamiliar with some intricacies on how Python (not just SqlAlchemy) approach certain things, and are overthinking things.

Hey Jonathan,

I probably should give a quick blurb about me so people understand where I'm coming from: Earlier I added some low level asserts to the OSX kernel, FreeBSD kernel, and JunOS kernels. My freebsd work is on github/splbio, I've added to a few projects outside of FreeBSD as well, git and a few others.
CTO okcupid 2005-2007 (did the initial scaling work, C++/python)
Leader of FreeNAS project (kernel+python django) ~2011-2012
Build a 10gig threat appliance (kernel+python django) 2012-2015
Currently I'm building a new startup based on flask+sqlalchemy, to be fair our scaling issues aren't as huge these days, but would be nice to start a dialog with the community on how to scale certain things, including debugging so that pushes to prod allow for debugging of new features for select users.

Anyhow, I really don't see a problem with having logging on prod, provided that it's not doing to impact performance across the board and this is why I asked the questions I did.

I'm going to poke around and see what I can/can-not use from this discussion.

What does however have me worried is that I'm getting the impression that this community might not be one that shares the same methodologies that I've used in the past to be successful in my projects. I'm hoping we can learn from each other, moving away from sqla and flask would be very very painful for us, so I hope we can come to a situation where ideas and code can be shared to improve everyone's experiences.

Maybe now that I've shared my background we can have a more open discussion and not make assumptions about skill levels and backgrounds.


SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper


To post example code, please provide an MCVE: Minimal, Complete, and Verifiable 
Example.  See  http://stackoverflow.com/help/mcve for a full description.
--- You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.

Reply via email to