On Wednesday, April 13, 2016 at 7:25:16 PM UTC-4, Mike Bayer wrote:
>
> Well scopedsession.remove throws away the session, so yeah either don't
> call that , or set up the connection immediately on the next session.
I thought "this is obvious, the session is closed on `remove`", but then
Will the connection.info dict always be new if a new
underlying raw connection has been grabbed? (Such that I can reliably
detect this situation?)
On Wednesday, April 13, 2016, Mike Bayer wrote:
> Well scopedsession.remove throws away the session, so yeah either
Well scopedsession.remove throws away the session, so yeah either don't
call that , or set up the connection immediately on the next session.
On Wednesday, April 13, 2016, Kent Bower wrote:
> About a year ago you helped me ensure my scoped session gets the same
> connection
On Monday, April 11, 2016 at 3:58:59 PM UTC+2, Ryan Govostes wrote:
The documentation would be improved by switching to more intuitive
examples. How about
One To Many, Many To One: Countries and Cities
One To One: Capitals and Countries
Many To Many: Organizations and Members
I like this. Make
About a year ago you helped me ensure my scoped session gets the same
connection to the database, which might be important.
I found out using "bind=connection" doesn't guarantee the session_maker
uses that connection if something went wrong with the session and
ScopedSession.remove() was called.
three people chimed in on this thread in 20 minutes. Surely some work
can be done amongst those interested parties (share email addresses!
get on irc!) to try to get this working that I can just review and
merge ? :)
On 04/13/2016 07:57 AM, David Moore wrote:
On 04/13/2016 07:50 AM, Piotr Dobrogost wrote:
Mike,
Thanks for your reply!
On Wednesday, April 13, 2016 at 1:15:32 PM UTC+2, Mike Bayer wrote:
We've not started supporting new oracle 12c features as of yet, in
this case it might be possible to get it working with some dialect
- Original Message -
From: "Piotr Dobrogost"
To: "sqlalchemy"
Sent: Wednesday, April 13, 2016 1:50:19 PM
Subject: Re: [sqlalchemy] Support for Oracle 12c auto increment (IDENTITY)
columns?
Mike,
Thanks
Mike,
Thanks for your reply!
On Wednesday, April 13, 2016 at 1:15:32 PM UTC+2, Mike Bayer wrote:
>
> We've not started supporting new oracle 12c features as of yet, in this
> case it might be possible to get it working with some dialect flags since
> we already use "returning" to get at the
On Wed, Apr 13, 2016 at 07:15:27AM -0400, Mike Bayer wrote:
> We've not started supporting new oracle 12c features as of yet, in this
> case it might be possible to get it working with some dialect flags since
> we already use "returning" to get at the newly generated primary key,
> although
We've not started supporting new oracle 12c features as of yet, in this
case it might be possible to get it working with some dialect flags since
we already use "returning" to get at the newly generated primary key,
although testing would be needed and other assumptions in the dialect might
get in
Hi all!
At
http://docs.sqlalchemy.org/en/latest/dialects/oracle.html#auto-increment-behavior
we read that:
"With the Oracle dialect, a sequence must always be explicitly specified to
enable autoincrement."
However, starting with version 12c Oracle supports autoincrement columns
(see update
12 matches
Mail list logo