[sqlalchemy] Re: Error when upgrading to 0.7.5 from 0.7.3 in subqueryload()
Ah! Cool, that makes sense. Changed the code to: # query = db.query(User).options(subqueryload(User.web_login), subqueryload(User.facebook_connect)) Upgraded to 0.7.5. And that did the trick, now both tables are loaded as subqueries. Thank you Michael! Much appreciated! /JT On Feb 13, 4:44 pm, Michael Bayer mike...@zzzcomputing.com wrote: On Feb 13, 2012, at 10:18 AM, Jevgenij wrote: Hi SQLAlchemy users, We are using SQLAlchemy for our new web app, and ran into a problem, still learning and are unsure if we found a bug or we are just using the framework wrong. We have a table called user and two child tables: -- class FacebookConnect(Base): __tablename__ = 'facebook_connects' ... user = relationship(User, backref=backref('facebook_connect', uselist=False)) class WebLogin(Base): __tablename__ = 'web_logins' ... user = relationship(User, backref=backref('web_login', uselist=False)) - user and the other two tables have a 1..1 --- 0..1 relationship. In our admin we load a list of users like this: users = db.query(User).options(subqueryload(User.web_login, User.facebook_connect)) The bug was actually fixed in 0.7.5 which is that it was silently failing to report that this is the wrong usage. You want to use two subqueryload() directives here, one for User.web_login, one for User.facebook_connect. The XYZload() directives only handle one path through the model each; the multiple entries is so you could say subqueryload(User.web_login, WebLogin.widgets) which would cause WebLogin.widgets to be subqueryloaded as soon as User.web_login were lazy loaded, or subqueryload_all(User.web_login, WebLogin.widgets) to load both. But in both cases its one path. -- 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] DetachedInstanceError after transaction
I seem to get this after I call a transaction.commit sqlalchemy.orm.exc.DetachedInstanceError DetachedInstanceError: Instance Useraccount at 0x103f9f610 is not bound to a Session; attribute refresh operation cannot proceed In the following code, the first call will print the id [ i called a flush() previously ], however the second call will generate the error. print userInstance.id transaction.commit() print userInstance.id anyone have a clue what i can do ? sqlalchemy is running under pyramid and transaction , and I'm using a declarative base. I will admit that i have some janky db sessioning stuff going on behind the scenes as I get used to pyramid and the new sqlalchemy. i've cobbled this together from some legacy code and current https://github.com/jvanasco/pyramid_sqlassist , and its driving the app in question. i can't seem to understand why transaction would clear the session data out though. -- 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] DetachedInstanceError after transaction
On Tue, Feb 14, 2012 at 6:48 PM, Jonathan Vanasco jonat...@findmeon.com wrote: I will admit that i have some janky db sessioning stuff going on behind the scenes as I get used to pyramid and the new sqlalchemy. Then I'd say the janky db sessioning stuff going on behind the scenes is closing your session after the commit. -- 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: DetachedInstanceError after transaction
my stuff doesn't handle the transaction commit - that's purely transaction / pyramid_tm so i'll look into that code to see if its closing it. great lead, thanks. -- 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] Re: DetachedInstanceError after transaction
Hi Jonathan, It's pyramid_tm -- it will clear the session on commit. It's counter-intuitive (or at least it was for me) if you've spent a lot of time with SQLAlchemy and using sessions directly, but you should try flush instead of commit: print userInstance.id DBSession.flush() print userInstance.id Then your view will still have access to the userInstance object after adding/updating it, but pyramid_tm to commit the transaction for you. I know there's been a lot of discussion about this and there are many other ways of handling it, but from the perspective of porting Pylons to Pyramid + pyramid_tm, swapping out commit() for flush() covers a lot of cases and still lets you handle IntegrityError and other exceptions. We should probably move this to the Pylons/Pyramid list if there are more questions though. Hope this helps! Eric On Tue, Feb 14, 2012 at 2:09 PM, Jonathan Vanasco jonat...@findmeon.comwrote: my stuff doesn't handle the transaction commit - that's purely transaction / pyramid_tm so i'll look into that code to see if its closing it. great lead, thanks. -- 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. -- 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: DetachedInstanceError after transaction
that seems to be it... when you commit, there is a call to _finish() http://www.zodb.org/zodbbook/transactions.html#commit _finish() is documented under abort() http://www.zodb.org/zodbbook/transactions.html#abort and it includes a session.close() -- 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: DetachedInstanceError after transaction
could anyone point in the right direction to either: 1. rebind an object to a new session or 2. allow objects to still be 'read' in the detached state ? -- 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: DetachedInstanceError after transaction
eric- thanks. I'll post a followup on the pylons list. i've already got a call to session.flush() the problem is that i need the transaction itself committed in this block. i have a series of database transactions that happen within the request. the first database transaction should error out on a fail and it's very important to save that information for perpetuity. subsequent database transactions could fail , and are just hidden. it sounds like the design of pyramid_tm is one transaction per request, which is really weird. -- 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] Re: DetachedInstanceError after transaction
On Tue, Feb 14, 2012 at 7:19 PM, Jonathan Vanasco jonat...@findmeon.com wrote: could anyone point in the right direction to either: 1. rebind an object to a new session or 2. allow objects to still be 'read' in the detached state ? Eric said it best: replace commit with DBSession.flush() -- 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] Re: DetachedInstanceError after transaction
Jonathan, You probably want transaction.savepoint() in that case. There's a pretty extensive discussion here showing savepoints (and rollbacks to savepoints) as a way of creating sub-transactions with pyramid_tm: https://groups.google.com/d/msg/pylons-discuss/5Mj4R3YMXhI/GVFj2Du33JAJ You can of course do all of that in SQLAlchemy without pyramid_tm doing it for you, so if the savepoints don't cover your use cases that's something to consider. -Eric On Tue, Feb 14, 2012 at 2:24 PM, Jonathan Vanasco jonat...@findmeon.comwrote: eric- thanks. I'll post a followup on the pylons list. i've already got a call to session.flush() the problem is that i need the transaction itself committed in this block. i have a series of database transactions that happen within the request. the first database transaction should error out on a fail and it's very important to save that information for perpetuity. subsequent database transactions could fail , and are just hidden. it sounds like the design of pyramid_tm is one transaction per request, which is really weird. -- 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. -- 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] Usage of begin nested
My use case requires that if insertion of object of Myclass succeeds then insert Object of Myclass1 . Even if inserting of Myclass1 object fails insertion of Myclass should not be rolled back. I mean adding Myclass is permanent and does not depend on failure or success of insertion of Myclass1. I have written following code and want to know if am understanding right usage of begin_nested and not writing buggy code. I am using postgresql 9.0 try: obj =Myclass() session.add(obj) if condition true: session.begin_nested() try: n = Myclass1(arguments) session.add(n) except SQLAlchemyError: db_session.rollback() session.commit() except SQLAlchemyError: session.rollback() raise Code is running f9, just want to make sure of some unknown gotcha in this code. Other option will be I commit after adding Myclass and perform insertion of Myclass1 in separate transaction but this way is not appealing to me. Regards, Manav Goel -- 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.