Re: [sqlalchemy] Re: SQLAlchemy + Elixir + Tornado overall setup

On Feb 10, 2011, at 3:22 PM, Romy wrote: > Got it. > > My remaining question: if I stick with autocommit=False and eventually > use a transactional engine, how does wrapping the entire request > inside a transaction (say my request starts off with a DB query) > affect performance compared to usi

[sqlalchemy] Re: SQLAlchemy + Elixir + Tornado overall setup

Got it. My remaining question: if I stick with autocommit=False and eventually use a transactional engine, how does wrapping the entire request inside a transaction (say my request starts off with a DB query) affect performance compared to using transactions inside only the critical areas. Is ther

Re: [sqlalchemy] Understanding logging output

On Feb 10, 2011, at 6:10 AM, Romy wrote: > I am testing autocommit=False, and the output pattern is consistently > missing a COMMIT. I don't quite understand what SQLAlchemy is doing in > its debug output, unless it's not printing everything that goes to > MySQL. Specifically, for code that looks

Re: [sqlalchemy] Dynamic relations...

On Feb 10, 2011, at 4:20 AM, Martijn Moeling wrote: > Another small thing: > > I took a look at: > > ForeignKeyConstraint(['invoice_id', 'ref_num'], ['invoice.invoice_id', > 'invoice.ref_num']) > > Now for Polymorphic tables: > > > in baseclass: > > baseclass.discriminator happens to be th

Re: [sqlalchemy] altering metadata when performing column changes

crap and I thought you were helping me answer emails today ! On Feb 10, 2011, at 10:37 AM, Chris Withers wrote: > Sorry, this was meant for the sqlalchemy-migrate group... > > Chris > > On 10/02/2011 13:19, Chris Withers wrote: >> Hi Domen, >> >> Am I right in remembering that last year you s

Re: [sqlalchemy] altering metadata when performing column changes

Sorry, this was meant for the sqlalchemy-migrate group... Chris On 10/02/2011 13:19, Chris Withers wrote: Hi Domen, Am I right in remembering that last year you said the alter_metadata=False was an experimental feature which turned out not to be useful and so could be removed? cheers, Chris

Re: [sqlalchemy] Re: SQLAlchemy + Elixir + Tornado overall setup

On Feb 10, 2011, at 6:05 AM, Romy wrote: > On Feb 7, 7:24 am, Michael Bayer wrote: >> My recommendation would be to call scopedsession.remove() at the end of a >> request. Though with an "async" server like Tornado, though I haven't used >> it, I'm not sure that "thread local" sessions, that

[sqlalchemy] altering metadata when performing column changes

Hi Domen, Am I right in remembering that last year you said the alter_metadata=False was an experimental feature which turned out not to be useful and so could be removed? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplist

[sqlalchemy] Re: SQLAlchemy + Elixir + Tornado overall setup

On Feb 7, 7:24 am, Michael Bayer wrote: > My recommendation would be to call scopedsession.remove() at the end of a > request.  Though with an "async" server like Tornado, though I haven't used > it, I'm not sure that "thread local" sessions, that is the default behavior > of a "scopedsession",

[sqlalchemy] Understanding logging output

I am testing autocommit=False, and the output pattern is consistently missing a COMMIT. I don't quite understand what SQLAlchemy is doing in its debug output, unless it's not printing everything that goes to MySQL. Specifically, for code that looks like this: user = User.query.filter_by(id=1).firs

[sqlalchemy] Dynamic relations...

Another small thing: I took a look at: ForeignKeyConstraint(['invoice_id', 'ref_num'], ['invoice.invoice_id', 'invoice.ref_num']) Now for Polymorphic tables: in baseclass: baseclass.discriminator happens to be the __tablename__ of the polymorphic ForeignKeyConstraint('['baseclass.discimina