[sqlalchemy] Re: Error when upgrading to 0.7.5 from 0.7.3 in subqueryload()

2012-02-14 Thread Jevgenij
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

2012-02-14 Thread Jonathan Vanasco
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

2012-02-14 Thread Claudio Freire
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

2012-02-14 Thread Jonathan Vanasco
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

2012-02-14 Thread Eric Rasmussen
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

2012-02-14 Thread Jonathan Vanasco
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

2012-02-14 Thread Jonathan Vanasco
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

2012-02-14 Thread Jonathan Vanasco
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

2012-02-14 Thread Claudio Freire
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

2012-02-14 Thread Eric Rasmussen
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

2012-02-14 Thread Manav Goel
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.