Thanks Simon. I think my train of thought isn't quite clear at this point. Sorry for this, I appreciate your comment and you are right I think I need to work on my understanding of two different session concept, it's a bit complex. On Jun 30, 2014 4:12 AM, "Simon King" <si...@simonking.org.uk> wrote:
> What you are suggesting is definitely not what I think of as the > traditional pattern for a web application (but I don't know exactly > what you are trying to do, so perhaps you have good reasons for doing > things this way). > > In the web applications that I write, there is no real state on the > server in between requests, except what is stored in the database. So > when a web request comes in, a new sqlalchemy session is created, the > data is loaded from the database, any necessary changes are made, the > data is flushed back to the database, and the session is closed. There > is never any need for data to be held in memory on the server between > web requests. > > From what you've written, it sounds like you might perhaps be > confusing the concept of "web sessions" with "database sessions". "web > sessions" are a mechanism for identifying a single user, and the > actions they are performing, across multiple web requests. They are > typically implemented using cookies, where the cookie can either > contain the session data itself, or it can contain a key to a set of > data in the database. However, they have nothing to do with SQLAlchemy > sessions. > > (I'm also a bit confused by your mention of hybrid_property. As far as > I'm concerned, hybrid_property is just a convenient mechanism to help > you avoid writing "self.FirstName + ' ' + self.LastName" everywhere, > even in queries) > > Simon > > > On Mon, Jun 30, 2014 at 11:28 AM, Bao Niu <niuba...@gmail.com> wrote: > > Hi Simon, > > Sorry for the poor explanation in my previous post. > > Let me try to clarify this using a flow here: > > > ------------------------------------------------------------------------------- > > 1st_web_request comes in to tell the server which person instances are > to be > > interested. because it involves hybrid_property, and query, so it needs a > > session here, let's call it session_#1; > > ==> > > entering a stage where session_#1 has to be active, or otherwise we will > > lose sync ability to update those hybrid_property. At this stage > session_#1 > > basically is just holding a bunch of queried associations of Person > > instances and their names, and standing by, waiting for any update of > > FirstName or LastName to construct a new hybrid_property of Full_Name on > the > > fly. > > ==> > > Now we have 2nd_web_request coming in, which carries a thread-local > session > > object of its own, let's call it collectively session_#2.(by the way I'm > > using cherrypy and built a plugin and tool to automatically bind a > session > > for each request) I plan to use this second session object(s) to hold a > > bunch of Person(not just their names, in comparison to session_#2). > > > > My design breaks down here, as I really am lost in how I can deal with > two > > differently cycled session objects. Or maybe this design itself is > flawed? > > Maybe I there is something I missed about session as a whole? > > > > > > On Mon, Jun 30, 2014 at 2:57 AM, Simon King <si...@simonking.org.uk> > wrote: > >> > >> I'm not sure I understand your application. Are you saying that you > >> have Person instances that stay in memory for longer than a single web > >> request? > >> > >> Simon > >> > >> On Sun, Jun 29, 2014 at 11:54 AM, Bao Niu <niuba...@gmail.com> wrote: > >> > Hi Mike, > >> > Thanks for your reply. In my case, the full_name attribute is a hybrid > >> > property using query on firstName and lastName. When I construct a > >> > Person > >> > instance, I need a session to query the names and build the full_name > >> > attribute on the fly. So do you think I should remove this session > >> > immediately after I have built full_name attribute? What if later on > my > >> > application changes this person's firstName? If the session is still > >> > alive > >> > it will expire full_name attribute automatically, but if the session > was > >> > removed, there won't be any automatic update on those hybrid_property, > >> > right? > >> > > >> > Doesn't this scenario justify a background thread? > >> > > >> > > >> > On Sat, Jun 28, 2014 at 7:14 AM, Mike Bayer <mike...@zzzcomputing.com > > > >> > wrote: > >> >> > >> >> > >> >> On 6/28/14, 7:13 AM, Bao Niu wrote: > >> >> > >> >> My situation is like this: > >> >> > >> >> I am developing a web application, which has a Person class, which > has > >> >> FirstName and LastName attributes. Now I want to build their full > name > >> >> attribute and make this full_name attribute queriable, by using > >> >> hybrid_property, which entails query and hence session. This session > >> >> for > >> >> querying hybrid_property has its life cycle as long as that > particular > >> >> Person instance is active in memory, as in the running process the > >> >> names > >> >> might get changed, and need to communicate to the database. > >> >> > >> >> In the mean time, in this application I also need another Session > >> >> instance > >> >> to contain those Person instances themselves, and this Session > instance > >> >> has > >> >> a quite different life cycle than the above one. I am using > >> >> cherrypy.request > >> >> to hold a thread-local session for this second purpose. > >> >> > >> >> Now it seems to me that both Session instances are necessary, I can't > >> >> use > >> >> one in place of the other. But because handling two sessions at the > >> >> same > >> >> time is inherently so confusing sometimes, I wonder if I am in the > >> >> right > >> >> direction? Is this generally considered bad? If it is, then how to > deal > >> >> with > >> >> it? Thanks in advance. > >> >> > >> >> > >> >> If this is a web application, having a session that isn't lifecycled > to > >> >> a > >> >> request seems like it runs in some kind of background thread or > >> >> something. > >> >> Otherwise, if its some session that stays open in the cherrypy app > >> >> while the > >> >> app is doing nothing, and is only used by requests (somehow? session > >> >> shouldn't be accessed by multiple things at once) not serving > requests, > >> >> that's bad. if you're using a Session as some kind offline cache, > >> >> that's > >> >> not what it's for and it won't do a good job of that because it isn't > >> >> threadsafe. > >> >> > >> >> think more in terms of database transactions. I use two sessions > >> >> all > >> >> the time when I want to separate transactions, a background job is > >> >> working > >> >> in a transaction for several seconds, but a second short transaction > is > >> >> used > >> >> to write messages to a log table, so that I can see the log table > grow > >> >> from > >> >> the outside while the long transaction keeps going. But database > >> >> transactions overall should be short, and never dormant waiting for > >> >> something to happen, they should be burning through the work they > have > >> >> to do > >> >> as fast as possible and completing. So should your sessions. > >> >> > >> >> -- > >> >> You received this message because you are subscribed to a topic in > the > >> >> Google Groups "sqlalchemy" group. > >> >> To unsubscribe from this topic, visit > >> >> https://groups.google.com/d/topic/sqlalchemy/CVIkd-WQiDM/unsubscribe > . > >> >> To unsubscribe from this group and all its topics, 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. > >> > > >> > > >> > -- > >> > 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. > >> > >> -- > >> You received this message because you are subscribed to a topic in the > >> Google Groups "sqlalchemy" group. > >> To unsubscribe from this topic, visit > >> https://groups.google.com/d/topic/sqlalchemy/CVIkd-WQiDM/unsubscribe. > >> To unsubscribe from this group and all its topics, 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. > > > > > > -- > > 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. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sqlalchemy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sqlalchemy/CVIkd-WQiDM/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- 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.
