[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
Hi, take a look at the current implementation. we are doing this part already, we're using inspect to look at kwargs. its not fragile at all. so im just proposing we add extra sniffing of dbapi.connect(), and that we also look in the query string for the full range of those parameters. this will allow 90% of what people want to pass to be allowed within the URI. Having kicked off this thread, I think my take now is to keep things more-or-less as they are - from all the points people have made, it's clear major changes will be more painful that it's worth. Having DefaultEngineStrategy.create pass the URI to the dialect's constructor would be great - that would let MSSQL have the module_name as a URI parameter. Just this change would statisfy my needs. Paul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
On Jul 10, 2007, at 12:06 PM, Rick Morrison wrote: Well the enumeration of the options targeted for a specific class has to be specified somewhere. Otherwise, we'll end up passing its constructor the entire dictionary of options, and it will raise errors because of invalid keywords. If there's some way to sniff the keyword arguments for a Dialect, Engine or Pool class, that could be used as the list. But to me, sniffing the keyword arguments is more fragile than just asking the instance for them, and if you're going to ask for them, why not specify the type as well? take a look at the current implementation. we are doing this part already, we're using inspect to look at kwargs. its not fragile at all. so im just proposing we add extra sniffing of dbapi.connect(), and that we also look in the query string for the full range of those parameters. this will allow 90% of what people want to pass to be allowed within the URI. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
ugh...i was so happy that Dialect could be written with normal
keyword arguments.while i want comprehensive, i didnt
necessarily want to require a getopt layer for every dialect (as
well as every Engine class, every Pool class, etc).
Well the enumeration of the options targeted for a specific class has to be
specified somewhere. Otherwise, we'll end up passing its constructor the
entire dictionary of options, and it will raise errors because of invalid
keywords.
If there's some way to sniff the keyword arguments for a Dialect, Engine or
Pool class, that could be used as the list. But to me, sniffing the keyword
arguments is more fragile than just asking the instance for them, and if
you're going to ask for them, why not specify the type as well?
cant we just agree that the only three types we want on the query
string are string/int/boolean ? if you need to send a callable
argument in, clearly that cant be embedded in a query string unless
you wanted to eval() something, which i think is beyond overkill.
Yeah callables and such are way out of scope here. Any arguments specified
in a dburi ought to be simple types that can be easily specified in a string
format. The string/int/boolean scheme sounds reasonable enough, but having
the parser guess at which to produce is bound to have it guess wrong on
occasion.
if a known collision exists, then the dialect constructor specifies a
prefixed keyword argument for that particular option, and installs it
in its get_dbapi_options() result. so the dialects do prefixing for
known conflicts only. (as usual, there is still connect_args={} too)
That works.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
just to add an option, sometimes i solve such flat-namespace-collisions by adding inner level of syntax in argument values + parsing them, e.g. for command line strings: myapp mainarg1=v1 mainarg2=v2 sqlite='arg1:val1,arg2:val2'. this is somewhat ugly too, and is even uglier to extend to more levels. in python syntax it is much better, e.g. func( mainarg1=v1, mainarg2=v2, hint4sqlite=dict(arg1=val1,arg2=val2), hint4postgres=... , engine =dict(... ) ) etc. but this is not just dburi-text anymore... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
Sorry about the sporadic posts, I'm travelling if we are going whole hog with query strings (basically we're talking about adding pool options mostly), a comprehensive solution needs to be added in DefaultEngineStrategy. All that sounds fine, if Paul is still interested, I'll work with him on the implementation if he wants. also, the system of typing the string args would have to be more automatic than it is now...id favor an auto-conversion that converts pure integer strings to ints, true/false to True/False, and the rest stays as string. this is so that writing a dialect doesnt require that you have to interpret all the given kwargs among several types. The nature of that kind of automatic typing sounds a lot like the job of parsing command line options to me. Maybe we can use a least a bit of the optparse or getopt module, or at least follow that pattern, and have each Dialect etc. provide a list of options they're interested in along with the expected type. The list of options then passed to that object would then be limited to that list of options, so that will help to eliminate potentially confusing options as well. Note that we haven't yet addressed the namespace collision issue head-on yet. Any insights there, beyond prefixes are ugly? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
On Jul 8, 2007, at 11:04 AM, Rick Morrison wrote: How about a simple scheme in which options meant for engine or dialect are prefixed with a tag that would differentiate them from other options that would be passed through to the DBAPI? Something like sa-echo or similar. Any other ideas? 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. 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. 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
Hi, do you mean, the URI would have args that are used by the DBAPI *or* the dialect ? right now, all query strings in the URI go to the DBAPI's connect() method. mixing them up I fear opens the door for name conflicts. what if some DBAPI were suddenly supported that had a connect() argument called echo ? Ah, is the current idea that URI parameters are passed to the DBAPI, and dialects should use create_engine args? If that's the intention, I understand your concerns about nameclashes. Actually, if that is the case, MSSQL is doing things slightly wrong and using URI params where we shouldn't be. This would raise an issue for me though - how do you control create_engine parameters for the unit tests? Paul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
On Jul 7, 10:06 am, Paul Johnston [EMAIL PROTECTED] wrote: If that's the intention, I understand your concerns about nameclashes. Actually, if that is the case, MSSQL is doing things slightly wrong and using URI params where we shouldn't be. This would raise an issue for me though - how do you control create_engine parameters for the unit tests? take a look at test/testbase.py. for DBAPI query args, they can be in the query string sent to --dburi. for other create_engine() args, we generally support them as explicit options accepted by testbase.py (such as postgres --serverside cursors) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
Hi, take a look at test/testbase.py. for DBAPI query args, they can be in the query string sent to --dburi. for other create_engine() args, we generally support them as explicit options accepted by testbase.py (such as postgres --serverside cursors) I see, guess we need to add a couple of MSSQL options there; the dbapi springs to mind. At the moment MSSQL has three URI params that only affect the dialect; they are not passed down to the DBAPI. From what you've said, I guess we should look at moving these to being parameters to create_engine. Perhaps we can make both work in 0.3.9, with a deprecation warning if you use the URI. Then in 0.4 we can drop support for the URI. Let me know what you think of this - I'll proceed if you reckon it's a good idea. Looks like you're having a busy week-end coding! All the best, Paul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Idea for 0.4: URI params / create_engine arguments
On Jul 7, 2007, at 11:32 AM, Paul Johnston wrote: Hi, take a look at test/testbase.py. for DBAPI query args, they can be in the query string sent to --dburi. for other create_engine() args, we generally support them as explicit options accepted by testbase.py (such as postgres --serverside cursors) I see, guess we need to add a couple of MSSQL options there; the dbapi springs to mind. At the moment MSSQL has three URI params that only affect the dialect; they are not passed down to the DBAPI. From what you've said, I guess we should look at moving these to being parameters to create_engine. Perhaps we can make both work in 0.3.9, with a deprecation warning if you use the URI. Then in 0.4 we can drop support for the URI. Let me know what you think of this - I'll proceed if you reckon it's a good idea. its fine with me, you and Rick can decide how you want to do that. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
