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.
