Hi Simon, The purpose was to flag those contained objects. These objects are created by the application's users (both container and contained). The user can either create the contained objects manually and let the application infer the container, or they can also create the containers manually. In cases where the contained objects are created manually (i.e. not in the context of a container), the behavior should be to reject on existing records. Otherwise, the behaviour should be to use existing records and only reject on the duplicates of the container itself (this is where I use the hash of the member IDs, to detect container duplicates). Since a container object can contain multiple objects, I want to be able to flag all of the contained objects which are preexisting.
Best regards, Bow On Thu, Aug 11, 2016 at 10:33 AM Simon King <si...@simonking.org.uk> wrote: > On Thu, Aug 11, 2016 at 8:30 AM, Wibowo Arindrarto > <w.arindra...@gmail.com> wrote: > > Dear all, > > > > I have a little problem with getting object states that have been flushed > > but not committed. As far as I understand, SQLAlchemy does not have an > > official object state corresponding to this. However, in my application I > > need to track such objects. My current approach is to listen to the > > ``after_flush`` session event, similar to the one outlined here. However, > > that gets messy quite quickly if I want to track different instances from > > different tables as the approach uses a global db.session.info state. > > > > For the record, I'm also open to suggestions / critiques on whether > tracking > > flushed but not committed objects are a good idea. The reason I am doing > > this is because I need to do something like ``get_or_create`` (get a > > database record if present, create it otherwise). But I'm doing this > > multiple times, and some objects may be a container of multiple other > > objects. To make the ``get_or_create`` query of these container objects > > simpler, I store the hash of the object IDs that it contains. Doing so > means > > that I need to have all the contained object IDs, which means I have to > at > > least flush the contained objects first before I can run > ``get_or_create`` > > on the container object. > > > > Now, my question is, is it possible to extend my models such that I can > > track the commit status of it? If so, how do I do it? If not, is there a > > better way to tackle my underlying problem (i.e. doing ``get_or_create`` > on > > a container object)? I am aware of the ``persistent`` state, but it does > not > > make the distinction on the commit status of an object. > > > > I don't really understand the question here - it's not clear to me why > get_or_create for the container objects is any different than > get_or_create for any other object, or what that has to do with > flushed-but-not-committed records. Why do you need to treat objects > that have been flushed but not committed any differently to committed > ones? > > Simon > > -- > 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/bUGk1QTaRIE/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 https://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 https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
