I'm connecting to a legacy database, some tables that I need to map in
sqla have no primary key. I've created views for such tables that map
the ROWID as the primary key. SQLAlchemy does a RETURNING clause when
I am connected to a more recent Oracle database, but not when
connected to 8i.
I've
On Aug 14, 2010, at 9:34 AM, Kent wrote:
I'm connecting to a legacy database, some tables that I need to map in
sqla have no primary key. I've created views for such tables that map
the ROWID as the primary key. SQLAlchemy does a RETURNING clause when
I am connected to a more recent Oracle
On Aug 13, 2010, at 10:22 PM, Peter Hansen wrote:
On Jun 24, 1:23 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Jun 24, 2010, at 12:35 PM, Torsten Landschoff wrote:
That's what I thought but it does not cure my problem.
e.raw_connect().isolation_levelis in fact None, but the rollback
Not a myth, I'm using them (via sqla). Simple views (just one table)
oracle figures out writes to all alone. For more complex views (joins
of tables), you can use an INSTEAD OF trigger to write to the view
(just pl/sql trigger where you tell Oracle what you want to happen when
someone
On Aug 14, 11:07 am, Michael Bayer mike...@zzzcomputing.com wrote:
In addition, isolation_level=None with pysqlite disables the DBAPIs
entire transactional system. SQLAlchemy relies upon this system to
handle proper transactional behavior.
So I consider this a pysqlite bug, and they should
I'm obviously missing some key concept as regards the management of sessions.
This seemingly simple usage fails:
def get_new():
sess = Session()
new = Something() # new orm object
sess.add(new)
sess.commit()
sess.close()
return new
new = get_new() # request a new
On Aug 14, 2010, at 12:04 PM, Peter Hansen wrote:
On Aug 14, 11:07 am, Michael Bayer mike...@zzzcomputing.com wrote:
In addition, isolation_level=None with pysqlite disables the DBAPIs
entire transactional system. SQLAlchemy relies upon this system to
handle proper transactional behavior.
On Aug 14, 2010, at 12:53 PM, Michael Hipp wrote:
I'm obviously missing some key concept as regards the management of sessions.
This seemingly simple usage fails:
def get_new():
sess = Session()
new = Something() # new orm object
sess.add(new)
sess.commit()
Michael
Thanks for taking the time to formulate a very thorough answer. (Now if I can
make my understanding be as thorough.)
If you could suffer me one more question ... it appears there are two* ways to
handle this inside a method that may not know where it's called from.
def
On Aug 14, 2010, at 3:00 PM, Michael Hipp wrote:
Michael
Thanks for taking the time to formulate a very thorough answer. (Now if I can
make my understanding be as thorough.)
If you could suffer me one more question ... it appears there are two* ways
to handle this inside a method that
On 8/14/2010 2:29 PM, Michael Bayer wrote:
The approach above may be fine for your needs but I wouldn't encourage it. The
demarcation of transaction boundaries shouldn't be an ad-hoc thing IMO and
granular functions shouldn't be deciding whether or not they are setting up a
transaction.
On Aug 14, 2010, at 3:54 PM, Michael Hipp wrote:
On 8/14/2010 2:29 PM, Michael Bayer wrote:
The approach above may be fine for your needs but I wouldn't encourage it.
The demarcation of transaction boundaries shouldn't be an ad-hoc thing IMO
and granular functions shouldn't be deciding
12 matches
Mail list logo
