On Dec 11, 2008, at 12:57 PM, Max Ischenko wrote:
> > Are you using Session.mapper ? That's the same behavior the > extension had in 0.4, save-on-init. I don't favor the usage of > Session.mapper. > > I do use Session.mapper. I recall I switched to it since I was > getting "Parent instance ... is not bound" error with sa.orm.mapper. > > I hastily put my SA-updated 0.5 into production and now my inbox > filled with hundreds of errors like: > > WebApp Error: <class 'sqlalchemy.exc.UnboundExecutionError'>: > Instance <CompanyPost at 0xb42606c> is not bound to a Session; > attribute refresh operation cannot proceed > > and > > WebApp Error: <class 'sqlalchemy.exc.ProgrammingError'>: > (ProgrammingError) (2014, "Commands out of sync; you can't run this > command now") > > and > > WebApp Error: <class 'sqlalchemy.exc.TimeoutError'>: QueuePool limit > of size 5 overflow 10 reached, connection timed out, timeout 30 > > I seems to have fixed the last one by adding these pool config lines > to my config.ini. > sqlalchemy.blog.pool_size = 15 > sqlalchemy.blog.max_overflow = 10 > > > Any ideas what I screwed up with the first two errors? you definitely need to get that code out of production until you work out your session usage. It seems likely that your app is relying on a certain behavior that we removed in 0.5 which is the get_session() method on Mapper. the 05Migration doc has a note about this which is probably easy to miss: get_session() - this method was not very noticeable, but had the effect of associating lazy loads with a particular session even if the parent object was entirely detached, when an extension such as scoped_session() or the old SessionContextExt was used. It's possible that some applications which relied upon this behavior will no longer work as expected; but the better programming practice here is to always ensure objects are present within sessions if database access from their attributes are required. You're the first person that has reported running into this issue in the 05 series so it seemed hopeful that the removal of this method wasn't going to have a big impact. A common pattern which can cause what you see there is if your templates are accessing lazy loaders on objects, but the Session which loaded those objects had been clear()'ed or otherwise closed before the template was allowed to render. You should try to keep the same Session open throughout the full request lifecycle, and you should avoid removing any objects from the Session which you wish to continue using. Alternatively, this kind of error may occur if you are using detached objects that are stored in a persistent cache. These objects wont "auto attach" when used for the same reason, and in fact even in the 0.4 series this is a dangerous pattern since globally accessible objects can be accessed by multiple threads. If you want to bring cached objects into a current session, bring them in using session.merge(dont_load=True). There's a recipe illustrating this in the distribution in examples/query_caching/query_caching.py if you want to see a working pattern. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
