the "key" argument to column doesnt work very well when you get into crazier mapping scenarios; there arent a lot of test cases that use it and it complicates things. it would be better if identifiers knew to quote themselves in a database-agnostic manner.
On Jul 30, 2006, at 7:42 AM, Aaron Spike wrote: > Michael Bayer wrote: >> ticket #155. theres some patches there that are very close to how it >> should be done. i didnt like the "quote_string" function being >> called so >> often but there might not be any way around that (i.e. maybe the >> quote=True flag not really worth it). >> >> what this patch would need is, support for other DB's that need >> it, and >> some unit tests. id most like the quoting to be used only when >> absolutely >> needed for only those identifiers that need it. and id very much >> like it >> to not introduce a bunch of new issues if at all possible. > > I'm sure I don't know enough to really comment on the method. As I was > confronted by the problem and I didn't know it was unsupported, my > first > inclination was to actually quote the identifiers while typing out the > table model. I figured if you are required to quote the names for the > database engine, why should this be any different. I realized from > there > that I couldn't use object notation to refer to these, so I tried > table.c['"Field_Name"']. It worked fine, but was cumbersome. So I > found > the key= parameter to the Column function. As I wrote in the reply > to my > original message, the next step was to add a simple line to filter the > identifier of any illegal characters when creating dbapi2 named > parameters. > > Coming at the problem from this direction shouldn't subject > everyone to > quoting. People who quote are already used to the pain of typing the > quotes. It is easy to test a string for quoting by checking that the > first or last character of the name is equal to the databases quoting > character. Using a mixed case name is not sufficient to determine > that a > identifier must be quoted because the db engine will by the standard > coerse unquoted identifiers. (I also think making this assumption > makes > the module less flexible for the individuals lucky enough to not have > quotes as they couldn't choose to use mixedcase identifers for easy > reading.) I haven't really digested the sql spec, but I believe quoted > identifiers can contain other characters that cannot be contained in a > legal name in python. > > What do you think of this direction at the problem? Do you see any > hidden gottchas? > > Aaron Spike ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
