you don’t need the session to be open to access object state.  when you close 
the session, the objects that were in it become detached.  if you are referring 
to them elsewhere, they still work fine.  they just won’t know how to go out 
and access a database.  if that’s all you need, you’re done.

the session being open represents an open transaction to the database, so the 
“state” you get from it is the “state” within a transaction - the objects 
within the session act as proxies for that state.    I’m sure you don’t want 
your application to have one transaction open permanently.

if you need those detached objects to also know about how to access a database 
when you use them, then you need to re-associate them with the current 
transaction (session.add() would do this).  However, if lots of threads are all 
hoping to do the same thing, then you really need to *copy* them as needed 
within each thread and associate them with that session’s thread.   The best 
way to do this is with session.merge(obj, load=False).

What you’ve now built is an in-memory object cache.     For a good example on 
how to build a full Query-level cached object system see 
http://docs.sqlalchemy.org/en/rel_0_9/orm/examples.html#module-examples.dogpile_caching
 .



On Feb 7, 2014, at 7:07 AM, Pavel Aborilov <abori...@gmail.com> wrote:

> Is it bad to use one session within app and never close it?
> 
> On Friday, January 31, 2014 9:04:01 AM UTC+4, Pavel Aborilov wrote:
> I need to have access to this state in a whole life of app, but as I 
> undestand it's not a good way to use one session all time.
> Proper way, to open session, do all my stuff with DB, then close session. But 
> then I lost my state.
> 
> In java I have DAO layer and business object, that store all my db field and 
> all my states regardless of session.
> but with SA I already have session, DBO object and Manager object. I dont 
> want to create so much layers, I think its not much pythonic.
> 
> 
> On Friday, January 31, 2014 12:51:41 AM UTC+4, Michael Bayer wrote:
> 
> On Jan 30, 2014, at 1:58 PM, Pavel Aborilov <abor...@gmail.com> wrote:
> 
>> Hi!
>> 
>> What is the best way to store runtime information in model?
> 
> attributes and columns have an .info property you can use, if this is 
> per-attribute
> 
> User.fullname.info[‘some_info’] = ‘bar’
> 
> 
> otherwise certainly, store any additional state on your object as needed, 
> it’s a regular Python object, “self._online = 0”, sure, thats great
> 
> 
>> If I get object from session like
>> user = session.query(User).get(1)
>> change state
>> user.online = 1
>> and after session.close() I have detached object
>> 
>> Do I always have to do expunge(user) after commit() and before close()
> 
> you never need to use expunge() and generally the Session is mostly intended 
> to be in progress when you work with your objects.  when you call .close(), 
> you should be done using all your objects - they’d either be gone, or stored 
> away in some kind of cache or something if you’re moving them to another 
> Session.
> 
> basically if you use the session as it is in the ORM tutorial, that’s the 
> main way to use it.  The Session is always there when you’re using objects.
> 
>> Is there any other ways?
> all kinds but you need to be more aware of object lifecycle if you’re coming 
> up with your own system.
> 
>> 
>> what is the most used practice, to create DAO layer or session it self work 
>> like DAO layer?
> 
> the Session itself is probably not suitable as a *large* scale DAO, for 
> simple things sure, but if your app has lots of complex use cases then its 
> better to have functions that represent those specific use cases directly.
> 
> -- 
> 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/groups/opt_out.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to