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<javascript:>> > 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.
