On Sat, Feb 12, 2011 at 8:11 PM, Michael Bayer <[email protected]>wrote:
> > On Feb 12, 2011, at 8:29 PM, Jon Nelson wrote: > > > > On Sat, Feb 12, 2011 at 6:51 PM, Michael Bayer > <[email protected]>wrote: > >> Hey list - >> >> The first beta release of SQLAlchemy 0.7 is available for download. >> > > Awesome! I just gave it a test and, except for being bit by the removal of > the _CursorFairy, it appears to work very well! I didn't do any formal > check, but it _feels_ faster. > > > so right there is the kind of surprise....I didn't even document the > _CursorFairy thing since I can't imagine how that affects anyone, unless you > for some reason were saying connection.connection.cursor.cursor to set some > attribute on the DBAPI cursor (gets were proxied through > __getattr__())....see thats *really* fringe > It's less "fringe" than "I was probably doing it wrong". :-) Please don't change it back, no "_CursorFairy" is a better situation. There are, however, three things I'd like to request before 0.7 is made > final. The first (largely taken from the url below) is an enhancement to > PGDDLCompiler. Currently, I monkey-patch it: > > ... > So for this one, since 0.6 you can less messily use sqlalchemy.ext.compiler > extension and redefine the compilation for the sqlalchemy.schema.CreateTable > construct, and just alter the output string with the extra options. > I spent a bit of time trying to do that and failed miserably. I tried this approach and it worked -- so I moved on. > That said adding support for postgresql_xxx options is fine and we can > probably lift and move that code above straight into the PG dialect as long > as we get some tests in test.dialect.test_postgresql, this is ticket #2051. > Fantastic! That code was authored by someone else, so I'm not the only one that would like to see this. > Yeah we'd need to come up with a convention for DB-specific constructs in > the Index construct. The creation/checking of them though can be > developed in a clean way for now using the approaches described at > http://www.sqlalchemy.org/docs/07/core/schema.html#controlling-ddl-sequences. > You'd have to have a SQL query that determines if the index exists. > The DDL() construct can be used to emit the CREATE/DROP statements, or you > could augment the compilation of the CreateIndex and DropIndex constructs, > or subclass CreateIndex/DropIndex with new constructs. If you want to send > me three SQL statements: 1. the statement to check for a given index, 2. the > statement to create, and 3. the statement to drop (if different from > default), I can illustrate a recipe on the wiki. > I just use DDL("CREATE INDEX....") for creation (and DROP, when appropriate). I'd like to see that "check for the existence of". What I do now is a sess.begin_nested() and then just try to create it, issuing sess.rollback() or sess.commit() as appropriate. There is one which I don't like to advertise because I don't want to be held > responsible for inadequate quoting - we like to rely upon the DBAPI and > binds for all quoting. That said I've updated the example with the > compiler method, and also added a big red warning that it's not tested as > safe against SQL injection. > Cool. -- Jon -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
