Re: [sqlalchemy] further restricting a query provided as raw sql
Michael Bayer wrote:
we have the in_() construct. It should be in the ORM and SQL expression
tutorials:
t1 = Table('mytable', metadata, Column('foo', String))
select([t1]).where(t1.c.foo.in_(['a', 'b', 'c']))
However, that requires table/column objects which I don't have.
Are the innards of in_ exposed anywhere for public consumption or should
I avoid?
Chris
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@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] session lifecycle and wsgi
-Original Message- From: sqlalchemy@googlegroups.com [mailto:sqlalch...@googlegroups.com] On Behalf Of Chris Withers Sent: 28 April 2010 14:37 To: sqlalchemy@googlegroups.com Subject: [sqlalchemy] session lifecycle and wsgi Hi All, I'm still trying to get an answer on this... Am I right in understanding that the basic session lifecycle should be: try: use session session.commit() except: log() session.rollback() finally: session.remove() The structure I've traditionally used with transactions has been: try: use session except: log() session.rollback() else: session.commit() Is this okay? Why would the first setup be preferable? (ie: what's wrong with my location of the commit() call?) What happens when the remove() call is omitted()? Have you read http://www.sqlalchemy.org/docs/session.html#lifespan-of-a-contextual-ses sion - it describes typical usage of a scoped session in a web application. In your traditional structure, you could get an exception during session.commit() which would not be handled in your exception handler. I believe (but I'm not certain) that after any kind of database exception, it is recommended that you roll back the existing transaction, as it is likely to be invalid anyway. Session.remove() ensures that the current session is removed from the scoped session registry. If you don't do this, I think that the next time this thread calls Session(), it'll get the old session back again, rather than creating a new one. Simon -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] ora-28547
HI I have been using the oracle database for my appliaction. i set the environment variables as export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/ server export PATH=$PATH:$ORACLE_HOME/bin export LD_LIBRARY_PATH=$ORACLE_HOME/lib export ORACLE_SID=XE I started the oracle instance ,and the listener is also in the work status. While running my app i got an error, follows the tracebacks.. File /root/tg2env/lib/python2.4/site-packages/SQLAlchemy-0.5.6- py2.4.egg/sqlalchemy/pool.py, line 304, in __init__ rec = self._connection_record = pool.get() File /root/tg2env/lib/python2.4/site-packages/SQLAlchemy-0.5.6- py2.4.egg/sqlalchemy/pool.py, line 161, in get return self.do_get() File /root/tg2env/lib/python2.4/site-packages/SQLAlchemy-0.5.6- py2.4.egg/sqlalchemy/pool.py, line 639, in do_get con = self.create_connection() File /root/tg2env/lib/python2.4/site-packages/SQLAlchemy-0.5.6- py2.4.egg/sqlalchemy/pool.py, line 122, in create_connection return _ConnectionRecord(self) File /root/tg2env/lib/python2.4/site-packages/SQLAlchemy-0.5.6- py2.4.egg/sqlalchemy/pool.py, line 198, in __init__ self.connection = self.__connect() File /root/tg2env/lib/python2.4/site-packages/SQLAlchemy-0.5.6- py2.4.egg/sqlalchemy/pool.py, line 261, in __connect connection = self.__pool._creator() File /root/tg2env/lib/python2.4/site-packages/SQLAlchemy-0.5.6- py2.4.egg/sqlalchemy/engine/strategies.py, line 80, in connect raise exc.DBAPIError.instance(None, None, e) sqlalchemy.exc.DatabaseError: (DatabaseError) ORA-28547: connection to server failed, probable Oracle Net admin error None None Any kind of help is appreciable. Thanks. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] session lifecycle and wsgi
Hi Chris: I'm a bit hesitant to share what I've done, b/c it's still a work in progress etc, but here goes: MySQL MyISAM, wait_timeout=28800 SQLAlchemy 0.5.6, pool_recycle=3600 I've written a few decorators (mostly stolen from SQLAlchemy docs examples): def with_query_write(fn): def go(self, *args, **kw): try: result = fn(self, *args, **kw) self.session.commit() return result except: self.session.rollback() raise return go def with_query_read(fn): def go(self, *args, **kw): try: return fn(self, *args, **kw) except: self.session.rollback() raise return go def with_session_write(fn): def go(*args, **kw): try: result = fn(*args, **kw) session.commit() return result except: session.rollback() raise return go All session writes go through base_dao.py, and are decorated with @with_session_write. This way the code isn't littered with session.add(), session.commit(), session.rollback() etc. @with_session_write def save(self, instance): session.add(instance) ... We've also extended Query (for reasons other than framing -- code omitted) and added @with_query_write and @with_query_read decorators. I don't love how I extended Query, and as of PyCon I know a better way to do this, but I haven't had a chance to re-implement it. Anyhoo, we pass the custom query class to the sessionmaker: session = orm.scoped_session(orm.sessionmaker(query_cls=FooQuery)) The custom query class: class FooQuery(Query): def __init__(self, *arg, **kw): Query.__init__(self, *arg, **kw) ... @with_query_read def all(self): return Query.all(self) @with_query_write def delete(self): return Query.delete(self) ... Finally, we're using pylons and are removing the contextual session in the finally clause of the base controller's __call__ method. class BaseController(WSGIController): def __call__(self, environ, start_response): try: ... finally: session.remove() We only ever see 'MySQL server has gone away' on our idle failover app instances, as the only traffic they get are occasional pings from nagios. I would have thought a combination of wait_timeout pool_recycle would prevent this... but I'm probably missing some piece of the big picture. OperationalError: (OperationalError) (2006, 'MySQL server has gone away') I do wonder how possible it would be wrt the open session in view etc to implement a reconnect on is_dissconect() in _handle_dbapi_exception()... I also wonder if there's some app out there using SQLAlchemy with an exemplary data access layer that we could all learn from. I should try a few code search engines... I went with DAOs (one per mapped table) which extend a base DAO that know how to do pagination, saves, deletes, etc. I dunno... Thanks fro asking Chris. I'm watching the answers to these threads too. --diana On Wed, Apr 28, 2010 at 9:37 AM, Chris Withers ch...@simplistix.co.ukwrote: Hi All, I'm still trying to get an answer on this... Am I right in understanding that the basic session lifecycle should be: try: use session session.commit() except: log() session.rollback() finally: session.remove() The structure I've traditionally used with transactions has been: try: use session except: log() session.rollback() else: session.commit() -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] session lifecycle and wsgi
Diana Clarke wrote: I'm a bit hesitant to share what I've done, b/c it's still a work in progress etc, but here goes: MySQL MyISAM, wait_timeout=28800 You have no transactions, so I'm not sure why you're worrying about them... Switch to InnoDB if you want transactions... Finally, we're using pylons and are removing the contextual session in the finally clause of the base controller's __call__ method. class BaseController(WSGIController): def __call__(self, environ, start_response): try: ... finally: session.remove() Yeah, I'm trying to find out if this .remove() is actually necessary. We only ever see 'MySQL server has gone away' on our idle failover app instances, as the only traffic they get are occasional pings from nagios. I would have thought a combination of wait_timeout pool_recycle would prevent this... but I'm probably missing some piece of the big picture. OperationalError: (OperationalError) (2006, 'MySQL server has gone away') Indeed, I would have thought so too... I do wonder how possible it would be wrt the open session in view etc to implement a reconnect on is_dissconect() in _handle_dbapi_exception()... I can't see this as being safe, the state of your app may be inconsistent, you should probably retry the whole wsgi request from scratch when that happens... ...and I know Michael doesn't like that idea either ;-) Chris -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] session lifecycle and wsgi
On Wed, Apr 28, 2010 at 7:52 AM, Chris Withers ch...@simplistix.co.uk wrote: Diana Clarke wrote: Finally, we're using pylons and are removing the contextual session in the finally clause of the base controller's __call__ method. class BaseController(WSGIController): def __call__(self, environ, start_response): try: ... finally: session.remove() Yeah, I'm trying to find out if this .remove() is actually necessary. .remove() as the final operation in a request ensures that no session state leaks from one web request to another. The next request in that thread or scoping context will get an entirely fresh session to work with. If finishing with a .remove() is a big deal in your environment, which it seems like it is, you could do a .remove() at the start of the request instead. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] session lifecycle and wsgi
Yup, no transactions (legacy, can't switch anytime soon) which is why I didn't originally write any rollback framing... but I was still getting the following error after MySQL raised a 2006 (until app restart), and a quick peek at _handle_dbapi_exception seemed to suggest that I needed to issue rollbacks even for non-transactional database engines. InvalidRequestError: Can't reconnect until invalid transaction is rolled back It goes without saying, but perhaps I've misunderstood something... --diana On Wed, Apr 28, 2010 at 10:52 AM, Chris Withers ch...@simplistix.co.uk wrote: MySQL MyISAM, wait_timeout=28800 You have no transactions, so I'm not sure why you're worrying about them... Switch to InnoDB if you want transactions... -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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: session lifecycle and wsgi
Chris, This is what the combination of repoze.tm2/transaction and zope.sqlalchemy does for you. You don't have to do anything special other than that. Laurence On Apr 28, 2:37 pm, Chris Withers ch...@simplistix.co.uk wrote: Hi All, I'm still trying to get an answer on this... Am I right in understanding that the basic session lifecycle should be: try: use session session.commit() except: log() session.rollback() finally: session.remove() The structure I've traditionally used with transactions has been: try: use session except: log() session.rollback() else: session.commit() Is this okay? Why would the first setup be preferable? (ie: what's wrong with my location of the commit() call?) What happens when the remove() call is omitted()? For me, the above will commonly be used in the context of a wsgi app (BFG to be precise). How do people manage the lifecycle in that context (ie: multi-thread, scoped sessions)? My thoughts were on a bit of wsgi middlewear so that I can manage the app's sessions without having to fiddle with BFG's wsgi application. I'll be using sessions in multiple databases to boot. Is there existing middlewear that does this? Is it a good/bad idea? cheers, Chris -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group athttp://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 sqlalch...@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: session lifecycle and wsgi
Laurence Rowe wrote: Chris, This is what the combination of repoze.tm2/transaction and zope.sqlalchemy does for you. You don't have to do anything special other than that. It doesn't do the .remove(). BFG currently has a bit of horribleness to make that work. I'd like to get rid of it or make it less horrible... Chris -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] session lifecycle and wsgi
jason kirtland wrote: On Wed, Apr 28, 2010 at 7:52 AM, Chris Withers ch...@simplistix.co.uk wrote: Diana Clarke wrote: Finally, we're using pylons and are removing the contextual session in the finally clause of the base controller's __call__ method. class BaseController(WSGIController): def __call__(self, environ, start_response): try: ... finally: session.remove() Yeah, I'm trying to find out if this .remove() is actually necessary. .remove() as the final operation in a request ensures that no session state leaks from one web request to another. The next request in that thread or scoping context will get an entirely fresh session to work with. Okay, would .close() be equivalent here? If finishing with a .remove() is a big deal in your environment, which it seems like it is, you could do a .remove() at the start of the request instead. What happens if you call .remove() on a virgin session? cheers, Chris -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] declarative commit hook - onCommit()?
Hi All, Let's say that when a database record is added or updated, I need to perform some arbitrary action (in my case, ensuring that data in other tables is consistent with what is being committed.) What mechanisms are suggested for this? I could add a save() method to my declarative class that I need to explicitly call but in an ideal world, there would be a way for me to specify a method such as onCommit() that would automatically get called if it exists. -Daniel -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] declarative commit hook - onCommit()?
Daniel Robbins wrote: Let's say that when a database record is added or updated, I need to perform some arbitrary action (in my case, ensuring that data in other tables is consistent with what is being committed.) What mechanisms are suggested for this? Mapper extesions: http://www.sqlalchemy.org/docs/05/reference/orm/interfaces.html#sqlalchemy.orm.interfaces.MapperExtension cheers, Chris -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] declarative commit hook - onCommit()?
On Wed, Apr 28, 2010 at 10:04 AM, Chris Withers ch...@simplistix.co.uk wrote: Daniel Robbins wrote: Let's say that when a database record is added or updated, I need to perform some arbitrary action (in my case, ensuring that data in other tables is consistent with what is being committed.) What mechanisms are suggested for this? Mapper extesions: http://www.sqlalchemy.org/docs/05/reference/orm/interfaces.html#sqlalchemy.orm.interfaces.MapperExtension Thanks, Chris. Right now I am not defining a mapper, just a bunch of declarative classes. Can I still use MapperExtensions? Or should I move away from pure declarative and use mappers directly? I might be leaning in that direction anyway... Regards, Daniel -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] session lifecycle and wsgi
On Wed, Apr 28, 2010 at 8:55 AM, Chris Withers ch...@simplistix.co.uk wrote: jason kirtland wrote: On Wed, Apr 28, 2010 at 7:52 AM, Chris Withers ch...@simplistix.co.uk wrote: Diana Clarke wrote: Finally, we're using pylons and are removing the contextual session in the finally clause of the base controller's __call__ method. class BaseController(WSGIController): def __call__(self, environ, start_response): try: ... finally: session.remove() Yeah, I'm trying to find out if this .remove() is actually necessary. .remove() as the final operation in a request ensures that no session state leaks from one web request to another. The next request in that thread or scoping context will get an entirely fresh session to work with. Okay, would .close() be equivalent here? Not really, .close is a Session method. See below. If finishing with a .remove() is a big deal in your environment, which it seems like it is, you could do a .remove() at the start of the request instead. What happens if you call .remove() on a virgin session? .remove() is specific to the ScopedSession container. It's not a Session method. It will .close() the session for the current scope, if any (which is effectively a no-op if there is a session but it hasn't performed any work), then remove that session from the scope. The next access to the ScopedSession container will produce a fresh session. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] declarative commit hook - onCommit()?
Daniel Robbins wrote: On Wed, Apr 28, 2010 at 10:04 AM, Chris Withers ch...@simplistix.co.uk wrote: Daniel Robbins wrote: Let's say that when a database record is added or updated, I need to perform some arbitrary action (in my case, ensuring that data in other tables is consistent with what is being committed.) What mechanisms are suggested for this? Mapper extesions: http://www.sqlalchemy.org/docs/05/reference/orm/interfaces.htm l#sqlalchemy.orm.interfaces.MapperExtension Thanks, Chris. Right now I am not defining a mapper, just a bunch of declarative classes. Can I still use MapperExtensions? The declarative docs include an example of using a MapperExtension: http://www.sqlalchemy.org/docs/reference/ext/declarative.html#mapper-con figuration Simon -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] declarative commit hook - onCommit()?
On Wed, Apr 28, 2010 at 10:25 AM, King Simon-NFHD78 simon.k...@motorola.com wrote: The declarative docs include an example of using a MapperExtension: http://www.sqlalchemy.org/docs/reference/ext/declarative.html#mapper-con figuration Great, thanks for everyone's help. This is exactly the info and functionality I need. Best Regards, Daniel -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] Implementing placeholders/get_or_insert over SA
I have code which generates mapped classes, some of which are actually already existing in the database ( I the sense that there is a corresponding row ). Example: given the declarative class class Frob(Base): __tablename__ = frobs id = Column(Integer, primary_key = True ) name = Column(String) nickname = Column(String) now, frobs contains the row id name nickname 1frobenius frobby The code i described needs to reference this row so it creates an instance Frob(frobenius, frobby). However, this is only meant as a placeholder and I don't want to create another row if one already exists. Is there any way to alter the Frob mapper in a way that specifies that the pair (name,nickname) should be unique ( I don't mean UniqueConstraint, since I have seen it only affects the table creation ) Thanks, M -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] session lifecycle and wsgi
jason kirtland wrote: On Wed, Apr 28, 2010 at 7:52 AM, Chris Withers ch...@simplistix.co.uk wrote: Diana Clarke wrote: Finally, we're using pylons and are removing the contextual session in the finally clause of the base controller's __call__ method. class BaseController(WSGIController): def __call__(self, environ, start_response): try: ... finally: session.remove() Yeah, I'm trying to find out if this .remove() is actually necessary. .remove() as the final operation in a request ensures that no session state leaks from one web request to another. The next request in that thread or scoping context will get an entirely fresh session to work with. If finishing with a .remove() is a big deal in your environment, which it seems like it is, you could do a .remove() at the start of the request instead. You really don't need the remove() if you have definitely called commit() or rollback() last, and you have expire_on_commit=True. In most cases the session will be empty on the next request. -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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 sqlalch...@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] session lifecycle and wsgi
Diana Clarke wrote: Yup, no transactions (legacy, can't switch anytime soon) which is why I didn't originally write any rollback framing... but I was still getting the following error after MySQL raised a 2006 (until app restart), and a quick peek at _handle_dbapi_exception seemed to suggest that I needed to issue rollbacks even for non-transactional database engines. InvalidRequestError: Can't reconnect until invalid transaction is rolled back It goes without saying, but perhaps I've misunderstood something... the database transaction is almost secondary to all the other things in memory that correspond to the transaction. Three FAQ entries below, and by the third the question should begin to be answered, hopefully... http://www.sqlalchemy.org/trac/wiki/FAQ#Thetransactionisinactiveduetoarollbackinasubtransaction --diana On Wed, Apr 28, 2010 at 10:52 AM, Chris Withers ch...@simplistix.co.uk wrote: MySQL MyISAM, wait_timeout=28800 You have no transactions, so I'm not sure why you're worrying about them... Switch to InnoDB if you want transactions... -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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 sqlalch...@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] session lifecycle and wsgi
Michael Bayer wrote: If finishing with a .remove() is a big deal in your environment, which it seems like it is, you could do a .remove() at the start of the request instead. You really don't need the remove() if you have definitely called commit() or rollback() last, and you have expire_on_commit=True. In most cases the session will be empty on the next request. When could it not be empty and would that matter? Are there any other implications of calling neither .remove() nor .close()? I have a (hopefully) paranoid worry about connections not being returned to the pool and/or going away in typical MySQL style... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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] session lifecycle and wsgi
Chris Withers wrote: Michael Bayer wrote: If finishing with a .remove() is a big deal in your environment, which it seems like it is, you could do a .remove() at the start of the request instead. You really don't need the remove() if you have definitely called commit() or rollback() last, and you have expire_on_commit=True. In most cases the session will be empty on the next request. When could it not be empty if GC has not removed objects from it yet, or you otherwise are still referencing those objects after you've finished your request. and would that matter? if your application keeps a handle on objects after the request is complete, and then passed them somewhere else, like a background thread or something, then the subsequent request is going to be potentially touching those objects at the same time. This would all be pretty poor practice as individual threads should always have their own sessions. Or maybe you loaded those objects into a globally-scoped in-memory cache of some kind - you probably don't want the next request touching them directly as once they're in a global cache of some kind, other threads would be calling upon them to copy their state locally. On the other hand, you might load the objects into a session-local cache of some kind that you've created.Now, when the next request comes in and calls upon those same rows, the ORM doesn't need to re-instantiate the objects, they are already present in the cache.This is a use case where you'd want to keep the same session from one request to the next. Its not one I use, but there is anotherORM like thing, somewhere on the webwhere I'm pretty sure they use a scheme like this. Are there any other implications of calling neither .remove() nor .close()? I have a (hopefully) paranoid worry about connections not being returned to the pool and/or going away in typical MySQL style... the bulletpoints at http://www.sqlalchemy.org/docs/session.html#lifespan-of-a-contextual-session are the best I can do here, I'm really just repeating myself over and over in these threads Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalch...@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 sqlalch...@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] Select.compare()
Hi all,
I faced a problem comparing Selects. It seems that Select.compare()
works incorrectly.
Here is the code that shows the problem:
from sqlalchemy import MetaData
from sqlalchemy import Table, Column
from sqlalchemy import Integer, String
from sqlalchemy import select
metadata = MetaData()
table1 = Table('table1', metadata,
... Column('col1', Integer, primary_key=True),
... )
s1 = select([table1])
s2 = select([table1])
assert s1.compare(s2)
Traceback (most recent call last):
File input, line 1, in module
AssertionError
Do I expect correctly that s1.compare(s2) should return True? If not,
how can I compare to Selects?
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@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] Select.compare()
dimazest wrote:
Hi all,
I faced a problem comparing Selects. It seems that Select.compare()
works incorrectly.
Here is the code that shows the problem:
from sqlalchemy import MetaData
from sqlalchemy import Table, Column
from sqlalchemy import Integer, String
from sqlalchemy import select
metadata = MetaData()
table1 = Table('table1', metadata,
... Column('col1', Integer, primary_key=True),
... )
s1 = select([table1])
s2 = select([table1])
assert s1.compare(s2)
Traceback (most recent call last):
File input, line 1, in module
AssertionError
Do I expect correctly that s1.compare(s2) should return True? If not,
how can I compare to Selects?
compare() is documented as producing an identity compare by default, i.e.
s1.compare(s1) would be True. compare() is currently only used by the
ORM for comparing the structure of column expressions and is not generally
useful on a FromClause at this time.
for a simple comparison of any two elements, just do:
def compare(x, y):
x = x.compile()
y = y.compile()
return unicode(x) == unicode(y) and x.params == y.params
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@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 sqlalch...@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] Mapper can't map primary key
Hi guys,
I have the following Table construction:
ADMIN_TABLE = Table('admin',
bound_meta_data,
Column('username', types.VARCHAR(100),
primary_key=True),
autoload=True, schema=schema)
and a mapper as such:
mapper(Admin, TABLES.ADMIN_TABLE,
properties={'employee':
relation(Employee, primaryjoin=
TABLES.ALL_EMPLOYEES_TABLE.c.employee_id==\
TABLES.ADMIN_TABLE.c.employee_id,
foreign_keys=[TABLES.ADMIN_TABLE.c.employee_id],
backref=backref('user',
foreign_keys=
[TABLES.ADMIN_TABLE.c.employee_id],
lazy=dynamic)
)
},
extension = VerificationMapper()
)
When I run paster serve --reload development.ini in my Pylons app, I
get an irritating error complaining the following:
sqlalchemy.exc.ArgumentError: Mapper Mapper|Admin|admin could not
assemble any primary key columns for mapped table 'admin'
As you can see above, I have already mapped the primary_key=True
property, why is it still complaining that it can't find the primary
key? With this error, I tried out something else, adding the code
below to my mapper configuration:
primary_key=[TABLES.ADMIN_TABLE.columns.username]
Adding this, allowed me to run the server properly, however, when I
query the database, it claims that it is unable to locate the username
column. I am very sure my database is correct and this is definitely
an issue with my SQLAlchemy code.
Can someone please explain what's going on? Why do I get the
exception? Thanks.
-Mark
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@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.
