On 7/8/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > thats ugly to me. if you know your DBAPI uses a certain argument, > you should be able to just pass it through. similarly i dont want > SA's args with some ugly prefix. prefixing is just a hack for > something this fundamental.
Well the DBAPI stuff *would* be passed through, the idea would be to process any SA-specific arguments before the DBAPI gets the remaing args, and to remove the SA-specific args to avoid confusing a DBAPI module with arguments that it won't recognize. Yeah, the prefix is a hack: it's the only kind of hack that can work in the flat namespace of a URL query string. Ideally there would be three namespaces, one each for the DBAPI module options, Dialect options, and engine options. But current frameworks aren't going to pass around three namespaces, they're going to pass a single dburi string. i would vote just for the each dialect making the decision as to what > arguments get interpreted how from the query string, it can do > wahtever it wants, end of story. That's what makes the most sense to me too. I think the argument regarding namespace collisions is a bit overstated when it comes to Dialect vs. DBAPI, as the Dialect is already specific to the DBAPI, and can simply avoid the problem by carefully choosing names. Collisions with options for other DBAPI's wont be a problem. also, the DefaultEngineStrategy > would pass the URI to the Dialect's constructor, and when it calls > for the "connect args", they are statefully set within the Dialect > based on the URI in the constructor; i.e. the get_connect_args() > method now takes no arguments. If I'm reading that right, it means the Dialect would parse its own options? That makes sense too, esp. for type conversion issues. Also all this discussion leaves out the engine options. Right now a user has to make their own provisions for getting both Dialect and engine config options into a program using SA. either by hardcoding the options in the engine creation code, or by a roll-your-own method to read the config data and get those options to the engine constructor. The dburi does a lot to ease this path for DBAPI options, all I'm saying is that it would nice to open the door somehow to engine and dialect options too. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
