Re: [sqlalchemy] SQLAlchemy 0.8.0b2 released
On Fri, Dec 14, 2012 at 1:11 PM, Michael Bayer mike...@zzzcomputing.comwrote: Hi list - SQLAlchemy 0.8.0b2 is released. This is hopefully the last beta for 0.8, as things have been mostly quiet surrounding 0.8.0b1, we had a few regressions fixed, and a bunch of other new bugs whose fixes are only in 0.8. There was a little bit of an additional refactor in this beta regarding the mechanics of loader strategies and aliased() constructs, which is to allow ever-more combinations of custom loader strategies in conjunction with polymorphic loading, and hopefully the latest architecture in this area will prove to be the most consistent yet. Other changes include that the Postgresql HSTORE type has been merged into the library, and there's also a handful of dialect fixes, notably several for Oracle.The Sybase dialect now supports schema reflection, and the new fdb dialect for Firebird should be working now. One thing to note here, is that I've put this release on Pypi.I had done this with 0.8.0b1, but then quickly pulled it off, as I had forgotten that tools like pip and easy_install don't honor the hidden flag on pypi, so even though I've kept 0.7.9 as the visible version, these tools still go out and grab the hidden beta - some prominent projects immediately reported that they got bumped up to 0.8 prematurely. But the effect of only publishing 0.8.0b1 on Sourceforge was that I didn't get the impression that we had so many people going out and testing the beta as we normally do. I was reminded by Chris McDonough that a project which really can't afford to jump to 0.8 on an automatic basis should have a requirement set up to keep them on 0.7. So we'll see how it goes -if your project needs to stay on 0.7, *please* set up a requirement for SQLAlchemy 0.8 in your requirements.txt and/or install_requires. Otherwise, you'll be a beta tester for 0.8.0b2. CHANGES for 0.8.0b2 are available in the documentation at: http://docs.sqlalchemy.org/en/rel_0_8/changelog/changelog_08.html#change-0.8.0b2 Download 0.8.0b2 at: http://www.sqlalchemy.org/download.html Thanks for the new release Mike. Just in time for the holidays! :-) I was using 0.8.0b1 in 3 recent projects, but none of them were pushing it very hard and everything just worked, so I didn't think I had anything to say. In retrospect, though, I guess It works for me is feedback on a beta just as much as bug reports? Anyway, 2 of those projects have gone into limbo due to corporate psychopathy, but the other one is still going strong and I'll start using 0.8.0b2 in it ASAP. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Sqlalchemy tuning : pool_size and pool_recycle
On Thu, Jun 28, 2012 at 11:45 PM, tonthon tontho...@gmail.com wrote: Hi, I was wondering what values to setup for pool_size and pool_recycyle parameters. I think you have to set them up regarding your sql server configuration (mysql in my case), but how ? I can only comment on pool_recycle because I've never had to change pool_size from its default. Setting pool_recycle is an application tuning thing. IIRC the default setting for MySQL is to drop connections after 8 hours of inactivity. If you always have activity on the connection more frequently than that, you shouldn't need to set pool_recycle. If your connection to MySQL can go quiet for long periods, use pool_recycle to essentially ping the connection to prevent the MySQL server from dropping it. I have an app that sees a few hits a day during business hours Mon-Fri. Without setting pool_recycle the first hit in the morning would typically fail because the connection had been dropped overnight. I set pool_recycle to 3600 (seconds) and had no more dropped connection problems. As with all app tuning issues, YMMV... Doug -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: Problem with coverage and sqlalchemy declarative synonym?
With some help from Ned Batchelder I was able to confirm that this is
a Python bug: http://bugs.python.org/issue1569356 that has been fixed
since the 2.5.2 release. Ned confirmed that the fix is included in
Python 2.6a3.
Doug
On Sep 16, 5:22 pm, Doug Latornell [EMAIL PROTECTED] wrote:
Thanks for the quick replies, Jason and Michael, and for the very
succinct test case. I will try to raise this with Ned Bachelor over
athttp://nedbatchelder.com/code/modules/coverage.html
Doug
On Sep 16, 4:55 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Sep 16, 2008, at 7:25 PM, Doug Latornell wrote:
Over on the TurboGears list a TG2 user pointed out a problem that
arises when nosetests --with-coverage is run on a project with a
sqlalchemy identity
model:http://groups.google.com/group/turbogears/t/7fd3639a5a4d4b8c
I dug into it and have reproduced the problem outside of TurboGears 2
and without nose:http://paste.turbogears.org/paste/7051
I've also shown that the problem isn't there for a plain Python
property (in contrast to a sqlalchemy
synonym):http://paste.turbogears.org/paste/7052
So, it looks like a problem maybe with the metaclass that sqlalchemy
uses to build properties, or with coverage not understanding what that
metaclass produces, or something. Or is there something else I'm
missing?
I've seen this identical issue with Bitten, and its not a SQLAlchemy
one.
Here's the ticket: http://www.sqlalchemy.org/trac/ticket/1138
Replace your test case with this script:
def foo(somearg):
class Bar(object):
def __getattr__(self, attribute):
return getattr(somearg, attribute)
assert 'somearg' not in Bar.__dict__
foo('hi')
I just ran it with the coverage.py that we have in SQLAlchemy and
the bug reproduces.
--~--~-~--~~~---~--~~
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] Problem with coverage and sqlalchemy declarative synonym?
Over on the TurboGears list a TG2 user pointed out a problem that arises when nosetests --with-coverage is run on a project with a sqlalchemy identity model: http://groups.google.com/group/turbogears/t/7fd3639a5a4d4b8c I dug into it and have reproduced the problem outside of TurboGears 2 and without nose: http://paste.turbogears.org/paste/7051 I've also shown that the problem isn't there for a plain Python property (in contrast to a sqlalchemy synonym): http://paste.turbogears.org/paste/7052 So, it looks like a problem maybe with the metaclass that sqlalchemy uses to build properties, or with coverage not understanding what that metaclass produces, or something. Or is there something else I'm missing? Doug --~--~-~--~~~---~--~~ 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: Problem with coverage and sqlalchemy declarative synonym?
Thanks for the quick replies, Jason and Michael, and for the very
succinct test case. I will try to raise this with Ned Bachelor over
at http://nedbatchelder.com/code/modules/coverage.html
Doug
On Sep 16, 4:55 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Sep 16, 2008, at 7:25 PM, Doug Latornell wrote:
Over on the TurboGears list a TG2 user pointed out a problem that
arises when nosetests --with-coverage is run on a project with a
sqlalchemy identity
model:http://groups.google.com/group/turbogears/t/7fd3639a5a4d4b8c
I dug into it and have reproduced the problem outside of TurboGears 2
and without nose:http://paste.turbogears.org/paste/7051
I've also shown that the problem isn't there for a plain Python
property (in contrast to a sqlalchemy
synonym):http://paste.turbogears.org/paste/7052
So, it looks like a problem maybe with the metaclass that sqlalchemy
uses to build properties, or with coverage not understanding what that
metaclass produces, or something. Or is there something else I'm
missing?
I've seen this identical issue with Bitten, and its not a SQLAlchemy
one.
Here's the ticket: http://www.sqlalchemy.org/trac/ticket/1138
Replace your test case with this script:
def foo(somearg):
class Bar(object):
def __getattr__(self, attribute):
return getattr(somearg, attribute)
assert 'somearg' not in Bar.__dict__
foo('hi')
I just ran it with the coverage.py that we have in SQLAlchemy and
the bug reproduces.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
