Re: [sqlalchemy] Session.close() implicite
Michael- FYI, memoized_property isn't documented. it looks to be in the active source, and there is a recipe for a roll-your-own memoized orm properties. On Monday, May 25, 2015 at 11:43:58 AM UTC-4, c.b...@posteo.jp wrote: > > I am quite new to Python and not familiar with the decorator concept. > What do you mean with "memoized thing"? And why could the decorators > help me here? SqlAlchemy and Pyramid both offer decorators that memoize/cache the results of a property call. They do all the case-logic your example uses. An example would be using a memoizing decorator like this: @memoized def session(self): return self.CreateSession() which would only execute the first time, and use a memoized/cached value on subsequent calls. The different frameworks that offer memoizing decorators implement them differently. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Session.close() implicite
On 5/25/15 11:43 AM, c.bu...@posteo.jp wrote: On 2015-05-25 11:12 Mike Bayer wrote: CreateSession and sessionmaker do the same thing. I'd lose one or the other. Yes, I will do so. For the memoized thing, I'd use a decorator like Pyramid @reify or SQLAlchemy's @memoized_property, wouldn't bother with all those conditionals and such. I am quite new to Python and not familiar with the decorator concept. What do you mean with "memoized thing"? And why could the decorators help me here? As for "the session would be destroyed/closed", I'd never rely on that, I see. The link helped. Of course the Gui-Dialog related to such a Controller instance will call a SessionCommit() ('OK' is pressed) or SessionRollback() ('Cancel' is pressed). So the controller instance itself call commit() or rollback() on its session object. Maybe you could implement a BasicController.__del__() to check the state of the Session if it is commited or rolled back. I mean if someone missed to call commit() or rollback() on int. But I am not sure if it is possible to ask a Session object for things like that. What do you think? don't use __del__(), it causes the object to be uncollectable and should be avoided. Also, the garbage collector in general is not predictable as to when it will fire off. If you use Pypy, the GC is no longer generational and might not invoke for a long time. Database connections are a lot more important than this and should not be left to an asynchronous GC thread for cleanup. that's a poor design, and it will lead to problems like connection pool overflows and deadlocks. I understand that. I thought the Session object would be destroyed automaticly when the controller is destroyed. And I think the Session take care of itself to release the resources while it is destroyed. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Session.close() implicite
On 2015-05-25 11:12 Mike Bayer wrote: > CreateSession and sessionmaker do the same thing. I'd lose one or > the other. Yes, I will do so. > For the memoized thing, I'd use a decorator like Pyramid @reify or > SQLAlchemy's @memoized_property, wouldn't bother with all those > conditionals and such. I am quite new to Python and not familiar with the decorator concept. What do you mean with "memoized thing"? And why could the decorators help me here? > As for "the session would be destroyed/closed", I'd never rely on > that, I see. The link helped. Of course the Gui-Dialog related to such a Controller instance will call a SessionCommit() ('OK' is pressed) or SessionRollback() ('Cancel' is pressed). So the controller instance itself call commit() or rollback() on its session object. Maybe you could implement a BasicController.__del__() to check the state of the Session if it is commited or rolled back. I mean if someone missed to call commit() or rollback() on int. But I am not sure if it is possible to ask a Session object for things like that. What do you think? > that's a poor design, and it will lead to problems like > connection pool overflows and deadlocks. I understand that. I thought the Session object would be destroyed automaticly when the controller is destroyed. And I think the Session take care of itself to release the resources while it is destroyed. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Session.close() implicite
On 5/25/15 6:08 AM, c.bu...@posteo.jp wrote: What do you think about that (simplified) code? An instance of this class would be added to any gui-class (e.g. a dialog) which handle data over SQLAlchemy. The session would be destroyed/closed correct when the Controller instance is destroyed, too. Correct? [code] import sqlalchemy as sa import sqlalchemy.orm as sao _engine = sa.create_engine('postgres://...') class BasicController(): """ """ def __init__(self): self._session = None def CreateSession(self): if self._session is not None: raise AttributeError('...') self._session = sao.sessionmaker(bind=_engine)() @property def session(self): """ """ if not self._session: self.CreateSession() return self._session CreateSession and sessionmaker do the same thing. I'd lose one or the other. For the memoized thing, I'd use a decorator like Pyramid @reify or SQLAlchemy's @memoized_property, wouldn't bother with all those conditionals and such. As for "the session would be destroyed/closed", I'd never rely on that, that's a poor design, and it will lead to problems like connection pool overflows and deadlocks. The Session holds onto database resources and those resources should be released explicitly when a web request is complete. See http://docs.sqlalchemy.org/en/rel_1_0/orm/session_basics.html#when-do-i-construct-a-session-when-do-i-commit-it-and-when-do-i-close-it. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.