DSN is the one keyword for "host" that is universally recognized as part of "odbc" proper, so it makes sense that host/port would be the exception case - especially considering it seems like we now have to pick among many formats for propagating host/port and are going to require some kind of "host_format"/"connect_type" or something for the host/port case anyway.
lets just nail this down so 0.5 can go out soon. lets also add awesome docs to our awesome new doc system. On Dec 10, 2008, at 4:42 PM, Rick Morrison wrote: > > Whats the status of 0.5, is DSN the default in trunk now ? > > DSN is the first choice in MSSQLDialect_pyodbc.make_connect_string > right now. > > That's not what I see. I just pulled the 0.5 trunk, which I haven't > been tracking lately. Still uses the 'dsn' keyword build a > connection string with DSN, otherwise defaults to the former dsn- > less connection string behavior. > > What Mike is taking about is an idea initially advanced by Marc- > Andre Lemburg to make the 'host' portion of the dburl to represent a > DSN for pyodbc connections (any supplied database name would be > ignored) for the 0.5 trunk, and have the existing dsn-less > connection behavior become a keyword-only kind of thing. > > I made a patch for that many moons ago, but never committed it; it > makes a lot of sense, and the 0.5 release would be an appropriate > time to introduce this kind of compatibilty-breaking behavior. But > there's been a rather surprising lack of fans for the idea, and I > would expect to hear some grumbling from users if/when we do it. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
