Re: [sqlalchemy] Guaranteeing same connection for scoped session

2016-04-13 Thread Jonathan Vanasco 


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 
dug into the docs -- and I can see how this is misleading.

The narrative docs 
(http://docs.sqlalchemy.org/en/latest/orm/session_api.html#session-and-sessionmaker)

Session = sessionmaker()
# bind an individual session to a connectionsess = Session(bind=connection


It's easy to miss the importance of "individual"

And then the API makes it seem like a bind(connection) would persist via 
sessionmaker. 

http://docs.sqlalchemy.org/en/latest/orm/session_api.html#sqlalchemy.orm.session.sessionmaker.__init__

   - *bind* 
   

 – 
   a Engine 
   

 or 
   other Connectable 
   

 with 
   which newly createdSession 
   

 objects 
   will be associated.

http://docs.sqlalchemy.org/en/latest/orm/session_api.html#sqlalchemy.orm.session.Session


   - *bind* 
   

 – 
   An optional Engine 
   

or Connection 
   

 to 
   which this Session should be bound. When specified, all SQL operations 
   performed by this session will execute via this connectable.


Unless one were more familiar, the `remove` behavior wouldn't be 
apparent... and the notion of a particular connection being bound to a 
Session Maker might seem like a good thing (it's actually not, because you 
would inherently preclude the utility of connection pools , aside from 
 other effects)

-- 
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.

Re: [sqlalchemy] Guaranteeing same connection for scoped session

2016-04-13 Thread Kent Bower 
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 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 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. Is there a way to guarantee this?
>>
>> See attached script that fails on version 1.0.12
>>
>> Is this the intended behavior when sessionmaker has a specific connection
>> as bind?
>>
>>
>>
>> On Mon, Mar 23, 2015 at 12:40 PM, Michael Bayer > > wrote:
>>
>>>
>>>
>>> Kent  wrote:
>>>
>>> > In cases where we interact with the database session (a particular
>>> Connection) to, for example, obtain an application lock which is checked
>>> out from database for the lifetime of the database session (not just the
>>> duration of a transaction), it is important that I guarantee future scoped
>>> session instances get the same connection (and, for example, the
>>> pool_recycle or something else has thrown out that connection and grabbed a
>>> new one).
>>> >
>>> > Please advise me where I can best implement this guarantee.  A Session
>>> subclass's connection() method seems it might be the appropriate place, but
>>> let me know if there is a better recipe.
>>>
>>> you’d want to create that Session associated with the Connection
>>> directly:
>>>
>>> my_session = scoped_session(bind=some_connection)
>>>
>>> then of course make sure you .close() it and .close() the connection at
>>> the end of the use of that session.
>>>
>>>
>>>
>>> >
>>> > The Session.connection() method's docs say:
>>> > "If this Session is configured with autocommit=False, either the
>>> Connection corresponding to the current transaction is returned, or if no
>>> transaction is in progress, a new one is begun and the Connection returned
>>> (note that no transactional state is established with the DBAPI until the
>>> first SQL statement is emitted)."
>>> >
>>> > If the session is one registered in my scoped registry, I'd like to
>>> always return the same connection to guarantee I am using the one with the
>>> database-side checked-out application lock.
>>> >
>>> > What's my best option?
>>> >
>>> > Thanks much!
>>> >
>>> > --
>>> > 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 http://groups.google.com/group/sqlalchemy.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "sqlalchemy" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/sqlalchemy/WcdRsvBTozk/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> sqlalchemy+unsubscr...@googlegroups.com.
>>> To post to this group, send email to sqlalchemy@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/sqlalchemy.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> 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.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sqlalchemy" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sqlalchemy/WcdRsvBTozk/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
>

-- 
You received this message because you are subscribed to the Google Groups

Re: [sqlalchemy] Guaranteeing same connection for scoped session

2016-04-13 Thread Mike Bayer 
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 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. Is there a way to guarantee this?
>
> See attached script that fails on version 1.0.12
>
> Is this the intended behavior when sessionmaker has a specific connection
> as bind?
>
>
>
> On Mon, Mar 23, 2015 at 12:40 PM, Michael Bayer  > wrote:
>
>>
>>
>> Kent > > wrote:
>>
>> > In cases where we interact with the database session (a particular
>> Connection) to, for example, obtain an application lock which is checked
>> out from database for the lifetime of the database session (not just the
>> duration of a transaction), it is important that I guarantee future scoped
>> session instances get the same connection (and, for example, the
>> pool_recycle or something else has thrown out that connection and grabbed a
>> new one).
>> >
>> > Please advise me where I can best implement this guarantee.  A Session
>> subclass's connection() method seems it might be the appropriate place, but
>> let me know if there is a better recipe.
>>
>> you’d want to create that Session associated with the Connection directly:
>>
>> my_session = scoped_session(bind=some_connection)
>>
>> then of course make sure you .close() it and .close() the connection at
>> the end of the use of that session.
>>
>>
>>
>> >
>> > The Session.connection() method's docs say:
>> > "If this Session is configured with autocommit=False, either the
>> Connection corresponding to the current transaction is returned, or if no
>> transaction is in progress, a new one is begun and the Connection returned
>> (note that no transactional state is established with the DBAPI until the
>> first SQL statement is emitted)."
>> >
>> > If the session is one registered in my scoped registry, I'd like to
>> always return the same connection to guarantee I am using the one with the
>> database-side checked-out application lock.
>> >
>> > What's my best option?
>> >
>> > Thanks much!
>> >
>> > --
>> > 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 http://groups.google.com/group/sqlalchemy.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "sqlalchemy" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/sqlalchemy/WcdRsvBTozk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> sqlalchemy+unsubscr...@googlegroups.com
>> 
>> .
>> To post to this group, send email to sqlalchemy@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/sqlalchemy.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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.
>

-- 
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.

[sqlalchemy] Re: Feedback on "Basic Relationship Patterns" docs

2016-04-13 Thread Piotr Dobrogost 
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 Many To Many: Countries and Languages and this makes very 
nice example.

Regards,
Piotr Dobrogost

-- 
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.

Re: [sqlalchemy] Guaranteeing same connection for scoped session

2016-04-13 Thread Kent Bower 
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. Is there a way to guarantee this?

See attached script that fails on version 1.0.12

Is this the intended behavior when sessionmaker has a specific connection
as bind?



On Mon, Mar 23, 2015 at 12:40 PM, Michael Bayer 
wrote:

>
>
> Kent  wrote:
>
> > In cases where we interact with the database session (a particular
> Connection) to, for example, obtain an application lock which is checked
> out from database for the lifetime of the database session (not just the
> duration of a transaction), it is important that I guarantee future scoped
> session instances get the same connection (and, for example, the
> pool_recycle or something else has thrown out that connection and grabbed a
> new one).
> >
> > Please advise me where I can best implement this guarantee.  A Session
> subclass's connection() method seems it might be the appropriate place, but
> let me know if there is a better recipe.
>
> you’d want to create that Session associated with the Connection directly:
>
> my_session = scoped_session(bind=some_connection)
>
> then of course make sure you .close() it and .close() the connection at
> the end of the use of that session.
>
>
>
> >
> > The Session.connection() method's docs say:
> > "If this Session is configured with autocommit=False, either the
> Connection corresponding to the current transaction is returned, or if no
> transaction is in progress, a new one is begun and the Connection returned
> (note that no transactional state is established with the DBAPI until the
> first SQL statement is emitted)."
> >
> > If the session is one registered in my scoped registry, I'd like to
> always return the same connection to guarantee I am using the one with the
> database-side checked-out application lock.
> >
> > What's my best option?
> >
> > Thanks much!
> >
> > --
> > 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 http://groups.google.com/group/sqlalchemy.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sqlalchemy" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sqlalchemy/WcdRsvBTozk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> sqlalchemy+unsubscr...@googlegroups.com.
> To post to this group, send email to sqlalchemy@googlegroups.com.
> Visit this group at http://groups.google.com/group/sqlalchemy.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.exc import OperationalError

eng = create_engine('postgresql://salespylot:salespylot@localhost:5444/sqla', 
echo=True)
conn=eng.connect()
# bind to specific connection
Session = scoped_session(sessionmaker(bind=conn))

pid = conn.execute("select pg_backend_pid()").scalar()
raw_conn_addr = id(Session.connection().connection.connection)

metadata = MetaData(eng)
rocks_table = Table("rocks", metadata,
Column("id", Integer, primary_key=True),
)
class Rock(object):
pass
mapper(Rock, rocks_table)
metadata.create_all()


Session.query(Rock).all()

# See if normally get same connection
Session.remove()
Session.query(Rock).all()

# all is good: we got original connection again:
assert pid == Session.connection().execute("select pg_backend_pid()").scalar()
assert raw_conn_addr == id(Session.connection().connection.connection)

# something drastic happens to conn
aux_conn=eng.connect()
aux_conn.execute(text("select pg_terminate_backend(:pid)"), 
pid=pid)

try:
Session.query(Rock).all()
except OperationalError as e:
print e
# Error, framework automatically may issue this:
Session.remove()

Session.query(Rock).all()

# New connection has been created, didn't anticipate this...
newpid = Session.connection().execute("select pg_backend_pid()").scalar()
new_addr = id(Session.connection().connection.connection)
print "%d != %d; %d != %d" % (pid, newpid,

Re: [sqlalchemy] Support for Oracle 12c auto increment (IDENTITY) columns?

2016-04-13 Thread Mike Bayer 
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:





*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 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
newly generated primary key, although testing would be needed
and other assumptions in the dialect might get in the way.


Which flags do you have in mind? Looking at
http://docs.sqlalchemy.org/en/latest/dialects/oracle.html I don't
see anything which might be useful to make it work.

I was surprised Oracle needs different syntax with explicit sequence
in SA. Having one syntax for auto increment column (primary key)
across all backends seems like very important feature to have.  What
is the reason there's no Oracle dialect option to generate and use
suitable sequence for such column? Is there some recipe solving this
problem?


Regards,
Piotr Dobrogost

--
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.

 From the license under which you can use this
(http://www.oracle.com/technetwork/licenses/standard-license-152015.html):

*License Rights and Restrictions *
Oracle grants You a nonexclusive, nontransferable, limited license to
internally use the Programs, subject to the restrictions stated in this
Agreement, only for the purpose of developing, testing, prototyping, and
demonstrating Your application and only as long as Your application has
not been used for any data processing, business, commercial, or
production purposes, and not for any other purpose.

--

I suspect you would not be able to use this for developing and testing
sqlalchemy without breaking those terms.  Oracle can get really nasty
about using Developer Days when they think you've broken this agreement.

regards,

Dave Moore

--
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.


--
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.

Re: [sqlalchemy] Support for Oracle 12c auto increment (IDENTITY) columns?

2016-04-13 Thread Mike Bayer 



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
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 the way.


Which flags do you have in mind? Looking at
http://docs.sqlalchemy.org/en/latest/dialects/oracle.html I don't see
anything which might be useful to make it work.


they're module level flags on the dialect class itself like 
"postfetch_lastrowid" and "preexecute_autoincrement_sequences"




I was surprised Oracle needs different syntax with explicit sequence in
SA. Having one syntax for auto increment column (primary key) across all
backends seems like very important feature to have.  What is the reason
there's no Oracle dialect option to generate and use suitable sequence
for such column? Is there some recipe solving this problem?


Oracle (and Firebird) is the only database backend that until 12c did 
not provide any mechanism for auto-incrementing integer primary key 
columns.  SQLAlchemy doesn't want to get in the business of inventing an 
opinionated system for this.We don't ever dictate any details about 
how the schema is to be designed.








Regards,
Piotr Dobrogost

--
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.


--
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.

Re: [sqlalchemy] Support for Oracle 12c auto increment (IDENTITY) columns?

2016-04-13 Thread David Moore 



- 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 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 newly generated primary key, although testing 
would be needed and other assumptions in the dialect might get in the way. 




Which flags do you have in mind? Looking at 
http://docs.sqlalchemy.org/en/latest/dialects/oracle.html I don't see anything 
which might be useful to make it work. 


I was surprised Oracle needs different syntax with explicit sequence in SA. 
Having one syntax for auto increment column (primary key) across all backends 
seems like very important feature to have. What is the reason there's no Oracle 
dialect option to generate and use suitable sequence for such column? Is there 
some recipe solving this problem? 




Regards, 
Piotr Dobrogost 
-- 
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 . 


>From the license under which you can use this ( 
>http://www.oracle.com/technetwork/licenses/standard-license-152015.html ): 

License Rights and Restrictions 
Oracle grants You a nonexclusive, nontransferable, limited license to 
internally use the Programs, subject to the restrictions stated in this 
Agreement, only for the purpose of developing, testing, prototyping, and 
demonstrating Your application and only as long as Your application has not 
been used for any data processing, business, commercial, or production 
purposes, and not for any other purpose. 

-- 

I suspect you would not be able to use this for developing and testing 
sqlalchemy without breaking those terms. Oracle can get really nasty about 
using Developer Days when they think you've broken this agreement. 

regards, 

Dave Moore 

-- 
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.

Re: [sqlalchemy] Support for Oracle 12c auto increment (IDENTITY) columns?

2016-04-13 Thread Piotr Dobrogost 
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 newly generated primary key, 
> although testing would be needed and other assumptions in the dialect might 
> get in the way.


Which flags do you have in mind? Looking at 
http://docs.sqlalchemy.org/en/latest/dialects/oracle.html I don't see 
anything which might be useful to make it work.

I was surprised Oracle needs different syntax with explicit sequence in SA. 
Having one syntax for auto increment column (primary key) across all 
backends seems like very important feature to have.  What is the reason 
there's no Oracle dialect option to generate and use suitable sequence for 
such column? Is there some recipe solving this problem?


Regards,
Piotr Dobrogost

-- 
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.

Re: [sqlalchemy] Support for Oracle 12c auto increment (IDENTITY) columns?

2016-04-13 Thread Michal Petrucha 
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 testing would be needed and other assumptions in the dialect might
> get in the way.
> 
> Is there a free XE download for 12c yet?   I can do nothing until I can at
> least install that, unless you were able to work up patches on your end
> (which would be great anyway because I have no time these days).

There is a pre-installed VM with 12c available from
http://www.oracle.com/technetwork/database/enterprise-edition/databaseappdev-vm-161299.html

It's ridiculously slow (orders of magnitude slower than PG/MySQL
running on bare metal), but it works...

Cheers,

Michal

-- 
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.


signature.asc
Description: Digital signature

Re: [sqlalchemy] Support for Oracle 12c auto increment (IDENTITY) columns?

2016-04-13 Thread Mike Bayer 
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 the way.

Is there a free XE download for 12c yet?   I can do nothing until I can at
least install that, unless you were able to work up patches on your end
(which would be great anyway because I have no time these days).

On Wednesday, April 13, 2016, Piotr Dobrogost <
p...@2016.groups.google.dobrogost.net> wrote:

> 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 in this answer http://stackoverflow.com/a/11296469/95735).
>
> Does SQLAlchemy make use of this new feature of Oracle 12c so that it's
> not necessary to explicitly specify sequence in declaration of table
> columns (so that single declaration of such column works for Oracle and
> other databases)? If so, do I have to enable this somehow?
>
> Regards,
> Piotr Dobrogost
>
>
>
>
> --
> 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.
>

-- 
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.

[sqlalchemy] Support for Oracle 12c auto increment (IDENTITY) columns?

2016-04-13 Thread Piotr Dobrogost 
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 in this answer http://stackoverflow.com/a/11296469/95735).

Does SQLAlchemy make use of this new feature of Oracle 12c so that it's not 
necessary to explicitly specify sequence in declaration of table columns 
(so that single declaration of such column works for Oracle and other 
databases)? If so, do I have to enable this somehow?

Regards,
Piotr Dobrogost




-- 
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.