check out the very latest trunk and apply this patch:
Index: lib/sqlalchemy/databases/oracle.py
===
--- lib/sqlalchemy/databases/oracle.py (revision 2487)
+++ lib/sqlalchemy/databases/oracle.py (working copy)
@@ -409,6 +409,8 @@
I've done a little bit more testing and have found some interesting
results. If a connection has previously been established and it then
fails, I get a cx_Oracle exception. If a connection has yet to be
established, I get a SQLAlchemy exception.
These are the guys I'm seeing. If it would be he
our current work with auto-reconnect is checked in to the trunk,
including exception catches around rollbacks and commits.
so far it does seem to work with postgres, in a rudimental test.
the oracle routine is still not checked in.
On Apr 2, 2007, at 5:21 PM, Greg Copeland wrote:
>
>>> conn
> >connection, I then pulled my network cable and issued the execute on
> >my connection.
>
> Nice. I've been restarting the database server (for MSSQL, MySQL,
> Postgres) but I wonder if that will yield slightly different results.
>
If you need me to shutdown the database and retry, I can try th
Hi,
>I assume this means that the exception is not being caught and wrapped
>by an SQLAlchemy.exceptions exception?
>
We're going to identify the exception in a database-specific bit of code.
>cx_Oracle.DatabaseError: ORA-03114: not connected to ORACLE
>
>
Excellent, that's the snippet I nee
we should probably be wrapping the commit()/rollback() etc methods
for DB exceptions as well, currently its just execute() and cursor()
AFAIK.
On Apr 2, 2007, at 3:41 PM, Greg Copeland wrote:
>
>
>
> On Apr 2, 12:36 pm, Paul Johnston <[EMAIL PROTECTED]> wrote:
>> Greg,
>>
>> If you can send
On Apr 2, 12:36 pm, Paul Johnston <[EMAIL PROTECTED]> wrote:
> Greg,
>
> If you can send the traceback you get when such an error occurs, that
> would be helpful for providing Oracle support for this condition.
>
> Paul
>
I assume this means that the exception is not being caught and wrapped
by
On Apr 2, 2007, at 2:31 PM, Greg Copeland wrote:
> Okay, so what's SA's take on this problem domain? Applcation executes
> a query but the database has died between the time the connection was
> established and the time the query was executed. Does SA attempt to
> return an SA specific excepti
Please don't take my comment the wrong way. It's actually an off
handed compliment. SA seems fairly robust and developmentally
strong. As such, it's just surprising that something like error
handling doesn't have comprehensive coverage. Now I can certainly
understand why, since the DBAPI doesn
if you care to view trac, its ticket #516.
also, reasons like these are why i keep SA at a relatively low
version number (0.3) despite some saying this is underestimating.
in any case, as the experience with psycopg2 is illustrating, i am
not totally confident the state of DBAPI is going to
Frankly I'm very surprised this class of error has not been previously
addressed.
I'll have to test and see what happens. I was planning on doing the
defensive coding, followed by the testing to make sure it is caught
and recovers correctly.
Greg
On Apr 2, 12:36 pm, Paul Johnston <[EMAIL PRO
On Apr 2, 12:27 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
> this feature is not supported right now for most DB's except mysql
> but is being addressed in a current ongoing ticket and will be
> available in the next release.
I'm assuming you are talking about autoreconnect here? If so, I wo
Greg,
If you can send the traceback you get when such an error occurs, that
would be helpful for providing Oracle support for this condition.
Paul
Greg Copeland wrote:
>I'm using sqlalcehmy 2.5 with cx_Oracle 4.2.1. What is the proper way
>to detect an sqlalchemy operation has lost its data
this feature is not supported right now for most DB's except mysql
but is being addressed in a current ongoing ticket and will be
available in the next release.
however, its possible that some DBAPIs do not raise the error in a
manner which can ever be consistently caught; for example we've
14 matches
Mail list logo
