On Apr 8, 2006, at 7:47 PM, Daniel Miller wrote:
OK I'll admit, it may make more sense to pass a Schema object to the constructor of Table. I suppose that's fine since there's no higher-level object that will combine a group of schemas. Although we might want to think of using a different name since it will be confusing to do this:t = Table("mytable", schema, schema="public", ...)Those two schema parameters are different things, and we need them both.
its also not really a schema - its a colleciton of Table objects, which could, on the database side, be in multiple schemas. I also dont very much like names like "Group" or "TableGroup"....im leaning towards the name "VirtualSchema", for lack of anything else.
Also, VirtualSchema, or whatever name we call it, is going to inherit from the same parent that the SQLEngine does, although I have not fully determined this parent either. This is because I still want the original SQLAlchemy "table connects to engine connects to a connection pool" to be the "basic getting started" style of usage, which of course can be ditched for whatever methods are desired. VirtualSchema is also probably going to have a "connect" method that links it to some kind of datasource, since I also think the "ProxyEngine" style of operation has value as well and it will probably continue to be popular, unless someone comes in with some amazing connection-managing extension that blows it all away (feel free, whoever wants to contribute...).
one issue that makes decoupling of SQL dialects from the execution of SQL challening is that the various DB engines right now have the advantage that they can get involved with the details of execution...such as, some databases support lastrowid, some do not, some support sequences, some need some extra massaging for parameters, they can jump in to correct various "quirks" of the different DB APIs. just having an object that can compile SQL into a string, and a raw DBAPI connection, is not really enough.
------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
