Forgot to mention - this happens with SQLAlchemy versions 0.6.7 and
0.6.8.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
Thanks for the detailed explanation, Mike. It makes complete sense - I
missed the fact that a new Connection was being created under the hood
at different times in the two different scenarios.
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
to be an Elixir issue. It seems to be a subtle enough bug
(if bug it is) that removing Elixir from the picture causes the bug to disappear
from view.
Why should the two cases behave differently?
Regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
Thanks for the detailed explanation, Mike. I missed the fact that the Connection
gets created at different times in the two scenarios.
As expected, moving the echo=True line to just after the commit gives the same
result in both scenarios.
Regards,
Vinay Sajip
P.S. I'm reposting this, Google
the response
- so what would be a reasonably easy way of ensuring everything's
cleaned up? I don't believe that what I'm doing is a particularly
uncommon pattern.
Thanks regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post
,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group
still get
the AssertionError. With it, I don't - but doesn't a requirement to
call gc.collect() mean that there could be non-deterministic,
potentially long pauses during request handling, because of other
stuff needing to be garbage-collected which has no connection to the
SQLA stuff?
Regards,
Vinay
to be related to the connection being to a SQLite
database.
Regards,
Vinay Sajip
[1] http://groups.google.com/group/sqlalchemy/browse_frm/thread/5e08e49fa1722f91
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email
On Jun 14, 3:14 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Jun 14, 2010, at 9:56 AM, Vinay Sajip wrote:
There's really no way to tell what's happening in your app without an example
that illustrates the issue, such that if unusual behavior were observed, one
could issue a pdb
() for the first request leaves a state which causes
a different path to be taken by SQLA on the second request. How do I
completely clean up after each request so that the next identical
request is processed in the same way?
Regards,
Vinay Sajip
--
You received this message because you are subscribed
in it. That doesn't apply to a basic mod_wsgi
configuration.
I see now. It was a clutching-at-straws kind of thing :-)
Thanks regards,
Vinay Sajip
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch
something
really obvious?
Regards,
Vinay Sajip
[1]
http://groups.google.com/group/sqlalchemy/browse_thread/thread/fbca1399020f6a2e/
[2] http://paste.pocoo.org/show/223990/
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email
pointers
on how to get SQLA to execute
select setval('XXX_id_seq', max(id)) from XXX
I'm happy doing table and column reflection to decide when to make
these calls, but I want to stay at the SQLA layer so that my code
works unchanged on all mainstream databases.
Thanks for any pointers,
Vinay
,
Vinay Sajip
P.S. I think SQLAlchemy is great!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send
On Sep 18, 3:49 pm, Michael Bayer mike...@zzzcomputing.com wrote:
Vinay Sajip wrote:
hmmm OK I think what he may be referring to is that we have this flag
called echo which works like this:
engine = create_engine(url, echo=True)
what echo does is a shortcut to setting up logging
On Jan 16, 7:38 pm, Paul Johnston [EMAIL PROTECTED] wrote:
Hi,
'mssql://DSN=MyDSN'. How can I get this to work without specifying
You were nearly there...
mssql://?dsn=mydsn
Paul
Thanks, Paul,
For some reason it didn't work for me (sqlalchemy 0.4.2p3). I tried
mssql://?dsn=MyDSN, and
On Jan 17, 5:59 pm, Paul Johnston [EMAIL PROTECTED] wrote:
Hi,
For some reason it didn't work for me (sqlalchemy 0.4.2p3). I tried
mssql://?dsn=MyDSN, and also mssql://?DSN=MyDSN. Oh well.
Sorry, it's
mssql:///?dsn=mydsn
This definitely works, just tested it
eng =
that you have to the username password in the
URL, and an earlier (June 2007) thread about using Driver={} on Unix.
Is there an easy way to just pass the pyodbc connection to SQLAlchemy?
I couldn't spot anything obvious in the docs.
Thanks in advance,
Vinay Sajip
On 16 Jan, 18:10, Vinay Sajip [EMAIL PROTECTED] wrote:
I have a Windows setup in which I need to use Integrated
Authentication with pyodbc and MSSQL. I have set up a System DSN using
the Control Panel and pyodbc connects OK using this DSN - I can run
queries etc. without problems. I use
19 matches
Mail list logo
