Re: [sqlalchemy] What is the best way to store runtime information in model?
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.
Re: [sqlalchemy] What is the best way to store runtime information in model?
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. signature.asc Description: Message signed with OpenPGP using GPGMail
[sqlalchemy] What is the best way to store runtime information in model?
Hi!
What is the best way to store runtime information in model?
And is it good idea to store one in a model(like online/offline, etc)
for example:
class User(Base):__tablename__ = 'users'id = Column(Integer,
primary_key=True)username = Column(String, unique=True, nullable=False)
fullname = Column(String, default='')password = Column(String,
nullable=False)role = Column(String, nullable=False)
status = {0: Offline, 1: Online, -1: Unknown}
def __init__(self, **kwargs):
Base.__init__(self, **kwargs)self.init_status()
@orm.reconstructordef init_status(self):self._online = 0
@propertydef online(self):if self._online is None:
self._online = 0if self.enable:return self._online
return -1@online.setterdef online(self, value):if value !=
self.online:dispatcher.send(sender=self, signal=state,
value=value)self._online = value
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()
and then if I want to change it, I have to add it to new session and the again
commit,expunge,close
Is there any other ways?
P.S.
what is the most used practice, to create DAO layer or session it self work
like DAO layer?
Thanks.
--
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.
Re: [sqlalchemy] What is the best way to store runtime information in model?
On Jan 30, 2014, at 1:58 PM, Pavel Aborilov abori...@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. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [sqlalchemy] What is the best way to store runtime information in model?
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.comjavascript: 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.
