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.
