[sqlalchemy] Re: SAContext 0.3.0
Hi, SAContext is a SQLAlchemy front end that organizes your engines, metadatas, and sessions into one convenient object, while still allowing access to the underlying objects for advanced use. Mike, this looks like good work and something that is needed. I notice for instance that the current TurboGears SA integration is a little hacky (to say the least!) Does SAContext do anything in the way of assosciating transactions/sessions with requests? To explain why I'm interested, I'm having some data freshness problems with a TG/SA app. I believe SessionContext has some inherent thread-safety issues, primarily that old data will build up in each thread's identity map, unless you periodically start a new session (e.g. at the start of a request). Is this something that SAContext tries to address? Another thing SAContext could potentially do is handle database disconnection errors (i.e. reconnecting and retrying a block of code). This is something people often notice with MySQL. Automatic recovery is probably not appropriate for the SQLAlchemy layer, but perhaps SAContext is a layer where this can be done. 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: SAContext 0.3.0
Hi, SAContext is strictly a configurational object, it doesnt add any new I see. I had wondered if this was WSGI middleware that took care of database transactions (as has been mooted in the TG area recently). Obviously as a config object, it can't do either of the things I suggested. 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: SAContext 0.3.0
Well I would prefer not using None and rather making the user pass the correct key, so that way default become no different they using any other key and users could just as simply call their key main or what ever else turns them on. Assuming that they use the correct syntax in the ini file (sqlalchemy.key.uri). So what I would advocate is eliminating the special default and just make users specify the correct key, I think that would be much less ambiguous then None Jose On 7/11/07, Mike Orr [EMAIL PROTECTED] wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
On Wednesday 11 July 2007 21:49:48 Mike Orr wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). i would create a dummy class, in your case class DEFAULT: pass under SAcontext, and use that one instead of None: if x is SAcontext.DEFAULT: ... works quite well. --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
I've just reread the sacontext doc string and realize that what I've said really does not make any sense. To go back a step I would advocate using default rather then None Jose On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Well I would prefer not using None and rather making the user pass the correct key, so that way default become no different they using any other key and users could just as simply call their key main or what ever else turns them on. Assuming that they use the correct syntax in the ini file (sqlalchemy.key.uri). So what I would advocate is eliminating the special default and just make users specify the correct key, I think that would be much less ambiguous then None Jose On 7/11/07, Mike Orr [EMAIL PROTECTED] wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
On 7/11/07, Mike Orr [EMAIL PROTECTED] wrote: On 7/11/07, Jose Galvez [EMAIL PROTECTED] wrote: Dear Mike, I've read the doc string in the new sacontext and was just wondering why for add_engine_from_config do you have to explicitly pass None for the default connection? it would make more sense to pass 'default' or better yet nothing all all and assume the default engine. I understand that you are moving away from the the implicit to the explicit which is great, I just thought passing None to mean default is awkward when you could just as easily added None as the default in the method def. (the same could be said about add_engine) It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. I released 0.3.1 which accepts default, sacontext.DEFAULT, or None interchangeably to refer to the default engine. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: SAContext 0.3.0
On Jul 11, 2007, at 2:49 PM, Mike Orr wrote: It is awkward but Python has no other built-in value for default. Using a string means people may spell it differently, and the .metadata and .engine properties require a fixed value. Making it optional means the second positional argument would sometimes move to the first (like Pylons render_response(/template.html) vs render_response(mako, /template.html), and I'm absolutely opposed to that. Mike doesn't like positional arguments for SAContext but i think they make sense in these cases. So None was the best compromise I could find. i've no problem with positional arguments. I'm open to changing it to default if people like that better. It does mean people would have to pass the exact string or sacontext.DEFAULT (which used to exist but currently doesn't). id -1 on that, if possible. if theres some way for no arguments to do the right (i.e. expected) thing, thats best. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
