On Feb 12, 2011, at 8:29 PM, Jon Nelson wrote: > > > On Sat, Feb 12, 2011 at 6:51 PM, Michael Bayer <mike...@zzzcomputing.com> > 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 > > 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: OK well let me note first off that all of these things have way more chance of me getting around to them if theres a ticket in trac - otherwise theres no chance I'd remember seeing a feature request on the list. Second I'd note that we can certainly continue to put new features all throughout 0.7 - the move from 0.x to 0.y is for really big, destabilizing changes and things that are flat out backwards incompatible. What you have below are small feature adds that can go in anytime so there's no fear about the beta process. > > # See: http://www.mail-archive.com/sqlalchemy@googlegroups.com/msg20421.html > def patch_postgresql_table_ddl(): > import sqlalchemy.dialects.postgresql.base > class MyPGDDLCompiler(sqlalchemy.dialects.postgresql.base.PGDDLCompiler): > def post_create_table(self, table): > """Build table-level CREATE options like TABLESPACE.""" > > table_opts = [] > > inherits = table.kwargs.get('postgresql_inherits') > if inherits is not None: > if not isinstance(inherits, (list, tuple)): > inherits = (inherits,) > table_opts.append( > '\nINHERITS ( ' + > ', '.join(isinstance(i, basestring) and i > or self.process(i) > for i > in inherits) + > ' )') > > on_commit = table.kwargs.get('postgresql_on_commit') > if on_commit: > table_opts.append( > '\nON COMMIT ' + > on_commit.upper().replace('_', ' ')) > > with_oids = table.kwargs.get('postgresql_with_oids') > if with_oids is not None: > if with_oids: > w = 'WITH' > else: > w = 'WITHOUT' > table_opts.append('\n%s OIDS' % w) > > tablespace = table.kwargs.get('postgresql_tablespace') > if tablespace: > table_opts.append('\nTABLESPACE ' + tablespace) > > return ''.join(table_opts) > > sqlalchemy.dialects.postgresql.base.PGDDLCompiler = MyPGDDLCompiler > sqlalchemy.dialects.postgresql.base.PGDialect.ddl_compiler = MyPGDDLCompiler 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. 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. > The second thing I'd like to see is also postgresql-specific. I'd like to be > able to _create_ indexes with GIN or GIST. Right now I have to hoop-jump a > bit even to determine if they exist, much less create or manage them. 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. > > Lastly, it seems as though the recipe here: > > http://www.sqlalchemy.org/trac/wiki/UsageRecipes/PGValues > > doesn't do argument quoting and thus appears to suffer from SQL injection > possibilities. A safer and built-in mechanism for VALUES might be pretty > useful. 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. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
