-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Bayer ha scritto: > Manlio Perillo wrote: >> When writing this code I found some problems with SQLAlchemy: >> >> 1) There is no support for SQL Schema at all. >> >> It is ok, for me, if there is no direct support for SQL Schema in >> SQLAlchemy, but this is a standard feature, so SQLALchemy dialects >> should: >> >> * define a `supports_schemas` attribute, as a boolean >> * define a `has_schema` method, to check is a schema exists >> >> Can I fill a ticket with this feature request? > > can you describe this for me ? We support schemas from the perspective > that you can define a table that is in a particular schema, so i dont > understand the statement "no support for SQL schema at all". >
The "at all" was unnecessary, sorry. What I meant was that there is no support to check if a dialect supports schemas, and to check is a schema is already defined. > [...] > > `has_schema()` is a totally fine method for which we'd accept a patch to > the Inspector class as well as dialects. > Ok, thanks. I can only provide a patch for PostgreSQL, but it's a starting point. > >> 2) I would like to emulate SQL Schema support in SQLite, using secondary >> databases, attached to the main database. >> > [...] >> The problem is that SQLAlchemy executes these queries **before** my >> DDL listener is called, so the query fails because I don't have yet >> attached the secondary database. > > if your database requires special configuration in order for "schemas" to > be present, you would do that before issuing anything with metadata > creation. I'd advise using a PoolListener to handle this configuration. > It should not be the job of "create_all" to attach to a particular schema, > since "create_all" is not a "configure the database" command - many > applications don't ever call "create_all" but still may be using sqlite > schemas. > Please note that the code I have posted is only meant to support my current usage pattern of SQLAlchemy. PoolListener is rather low level; if I use them I need to know in advance the secondary databases to attach. > >> I think that this behaviour is incorrect. >> The "before-create" listeners of a MetaData object should be called >> before checking if the tables exist. > > I can see the awkardness here but the current contract of "before-create" > is that it means "before I create this list of Tables that I have found > need creation, and here they are". Its something we may have to revisit > if there's really a reason for a "before I do anything" hook - but I don't > buy the case of "I need to attach schemas in the create_all()" as a > necessary use case. Ok, fine for me. Auto attach database for SQLite it's not something i really need and it can still can be implemented using a PoolListener. See my reply to the more recent thread about Schema in SQLAlchemy about the reason why I was assuming that changing current behaviour was fine. Regards Manlio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktxNRIACgkQscQJ24LbaURRdACcCj51Sb5Gp1cqZNDUv3U6zM1Y LKgAn35CBel2vOrfkCd4yK5XMVMFf+V/ =xBEd -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
