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.
