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.
thanks,
-Alfred
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
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.
