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.
