Just a follow up to let you know SA 0.5 now runs smoothly on my site. Actually, it has been running for about a week now.
Onto your comments: I didn't use get_session() but I did use session.mapper instead of normal orm.mapper class. The reason for this is here http://tinyurl.com/2a76hp - I was getting exception about Parent not bound. Since site was (hastly) put in production and, worse of all, I couldn't reproduce the problem locally. Hence I tried several things at once. Something helped, though I can't tell what exactly. Alas. Here are the changes I did: 1. Use the same Session() instance through the request environ['sqlalchemy_session'] = sess = Session() (I used to use just Session class as is, without instantiating 2. Switched to sqlalchemy.orm.mapper and removed Session.extension = Session.extension.configure(save_on_init=False) I added a bit earlier My guess is the #1 was the root cause, though there are still a few places which just use Session (they are harder to refactor) yet it works fine. Max. 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. > > -- Max. http://www.developers.org.ua/m/max/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
