Re: [sqlalchemy] Is it considered bad practice to have more than one session instance simultaneously in a web application?
Thank you guys for your replies. These days I spent some time reading the documentation on session to make sure I understand all the basics. After reading, I still have trouble understanding the point that mapped objects should not outlive the session from which they are originally queried. In my case, a Person object loaded from database, having two attributes, o.FirstName, and o.LastName, is expected to persist within the full life-cycle of my application, not just a database session, because when you query the object you just make it visible to the application, you are not sure what you are going to flush into database at this moment. As Jonathan pointed out, merging seems to be the only way to extend the lifespan of those queried and mapped objects across different sessions. What I suggested in my previous post is having two (series of) sessions, one is responsible for querying and making FirstName(s) and LastName(s), and possibly concatenating the two; while the other (series of) sessions is responsible for holding all the Persons objects together and do some further query on them. Why is this design flawed?? Did I violate some fundamental principles here? Thanks. On Tue, Jul 1, 2014 at 8:24 AM, Jonathan Vanasco jonat...@findmeon.com wrote: That design is definitely flawed. Read up on the ORM session documentation, and pay attention to Merging, The session encapsulates a bit of logic and a unit of work. Once you close a session, the objects within it are considered to be out-of-phase. Accessing their attributes -- even only for a read -- requires a new database session/transaction to ensure that the data is the same. Sessions should generally last the length of a web request -- unless you have very specific business requirements that necessitate otherwise. In your case, you don't. Just start a session at the beginning of each request. You'll overcomplicate everything otherwise. -- 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.
Re: [sqlalchemy] Is it considered bad practice to have more than one session instance simultaneously in a web application?
I wouldn't say that you are violating a fundamental principle, I would just say that what you are suggesting isn't the normal structure of a web application. (Not that there is a normal structure for web applications really - it massively depends on the size of your audience. Something that works for a single user or a small number of users would be inappropriate for an application with vast numbers of users) If your web application keeps application state in its own process between requests, then you need to think very carefully about race conditions. For example, does your web application framework use threads? What happens if 2 requests try to operate on the same person at the same time? It also constrains your architecture if you want to scale up. If a web request loads the information it needs from the database, processes it, then flushes it back, then you can add multiple web frontend processes all talking to the same backend database. When a client makes an HTTP request, it doesn't matter which frontend handles that request, because all the state is in the database. Also, web requests tend to map quite nicely onto database transactions, which themselves are meant to be short lived. A long-lived database transaction has the potential to lock parts of the database, or at least increase the amount of accounting that the database has to do. It's possible that none of this matters for your application. If you only have a single user, the chance of threads clashing is fairly small. If you've come up with a solution that works for you, carry on :-) Hope that helps, Simon On Mon, Jul 14, 2014 at 12:07 PM, Bao Niu niuba...@gmail.com wrote: Thank you guys for your replies. These days I spent some time reading the documentation on session to make sure I understand all the basics. After reading, I still have trouble understanding the point that mapped objects should not outlive the session from which they are originally queried. In my case, a Person object loaded from database, having two attributes, o.FirstName, and o.LastName, is expected to persist within the full life-cycle of my application, not just a database session, because when you query the object you just make it visible to the application, you are not sure what you are going to flush into database at this moment. As Jonathan pointed out, merging seems to be the only way to extend the lifespan of those queried and mapped objects across different sessions. What I suggested in my previous post is having two (series of) sessions, one is responsible for querying and making FirstName(s) and LastName(s), and possibly concatenating the two; while the other (series of) sessions is responsible for holding all the Persons objects together and do some further query on them. Why is this design flawed?? Did I violate some fundamental principles here? Thanks. On Tue, Jul 1, 2014 at 8:24 AM, Jonathan Vanasco jonat...@findmeon.com wrote: That design is definitely flawed. Read up on the ORM session documentation, and pay attention to Merging, The session encapsulates a bit of logic and a unit of work. Once you close a session, the objects within it are considered to be out-of-phase. Accessing their attributes -- even only for a read -- requires a new database session/transaction to ensure that the data is the same. Sessions should generally last the length of a web request -- unless you have very specific business requirements that necessitate otherwise. In your case, you don't. Just start a session at the beginning of each request. You'll overcomplicate everything otherwise. -- 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] Is it considered bad practice to have more than one session instance simultaneously in a web application?
Thank you Simon for your informative reply! It's very information-rich and give me a new perspective to reflect on my design. It's really lucky for me to join this forum, I've been getting all such bonus knowledge all along!:) On Mon, Jul 14, 2014 at 5:48 AM, Simon King si...@simonking.org.uk wrote: I wouldn't say that you are violating a fundamental principle, I would just say that what you are suggesting isn't the normal structure of a web application. (Not that there is a normal structure for web applications really - it massively depends on the size of your audience. Something that works for a single user or a small number of users would be inappropriate for an application with vast numbers of users) If your web application keeps application state in its own process between requests, then you need to think very carefully about race conditions. For example, does your web application framework use threads? What happens if 2 requests try to operate on the same person at the same time? It also constrains your architecture if you want to scale up. If a web request loads the information it needs from the database, processes it, then flushes it back, then you can add multiple web frontend processes all talking to the same backend database. When a client makes an HTTP request, it doesn't matter which frontend handles that request, because all the state is in the database. Also, web requests tend to map quite nicely onto database transactions, which themselves are meant to be short lived. A long-lived database transaction has the potential to lock parts of the database, or at least increase the amount of accounting that the database has to do. It's possible that none of this matters for your application. If you only have a single user, the chance of threads clashing is fairly small. If you've come up with a solution that works for you, carry on :-) Hope that helps, Simon On Mon, Jul 14, 2014 at 12:07 PM, Bao Niu niuba...@gmail.com wrote: Thank you guys for your replies. These days I spent some time reading the documentation on session to make sure I understand all the basics. After reading, I still have trouble understanding the point that mapped objects should not outlive the session from which they are originally queried. In my case, a Person object loaded from database, having two attributes, o.FirstName, and o.LastName, is expected to persist within the full life-cycle of my application, not just a database session, because when you query the object you just make it visible to the application, you are not sure what you are going to flush into database at this moment. As Jonathan pointed out, merging seems to be the only way to extend the lifespan of those queried and mapped objects across different sessions. What I suggested in my previous post is having two (series of) sessions, one is responsible for querying and making FirstName(s) and LastName(s), and possibly concatenating the two; while the other (series of) sessions is responsible for holding all the Persons objects together and do some further query on them. Why is this design flawed?? Did I violate some fundamental principles here? Thanks. On Tue, Jul 1, 2014 at 8:24 AM, Jonathan Vanasco jonat...@findmeon.com wrote: That design is definitely flawed. Read up on the ORM session documentation, and pay attention to Merging, The session encapsulates a bit of logic and a unit of work. Once you close a session, the objects within it are considered to be out-of-phase. Accessing their attributes -- even only for a read -- requires a new database session/transaction to ensure that the data is the same. Sessions should generally last the length of a web request -- unless you have very specific business requirements that necessitate otherwise. In your case, you don't. Just start a session at the beginning of each request. You'll overcomplicate everything otherwise. -- 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.
Re: [sqlalchemy] Is it considered bad practice to have more than one session instance simultaneously in a web application?
That design is definitely flawed. Read up on the ORM session documentation, and pay attention to Merging, The session encapsulates a bit of logic and a unit of work. Once you close a session, the objects within it are considered to be out-of-phase. Accessing their attributes -- even only for a read -- requires a new database session/transaction to ensure that the data is the same. Sessions should generally last the length of a web request -- unless you have very specific business requirements that necessitate otherwise. In your case, you don't. Just start a session at the beginning of each request. You'll overcomplicate everything otherwise. -- 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] Is it considered bad practice to have more than one session instance simultaneously in a web application?
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 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] Is it considered bad practice to have more than one session instance simultaneously in a web application?
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
Re: [sqlalchemy] Is it considered bad practice to have more than one session instance simultaneously in a web application?
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
Re: [sqlalchemy] Is it considered bad practice to have more than one session instance simultaneously in a web application?
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
Re: [sqlalchemy] Is it considered bad practice to have more than one session instance simultaneously in a web application?
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.
[sqlalchemy] Is it considered bad practice to have more than one session instance simultaneously in a web application?
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. -- 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] Is it considered bad practice to have more than one session instance simultaneously in a web application?
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 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.
