Well, it is somewhat similar to my use case: there is a part (kind of a library) of the application which may load an object or it may transparently create one if it did not exist before. And there is a completely different part of the application which wants to do so something only if the object was freshly created (because it would be too expensive to do unconditionally) - but it has no idea where the object is coming from. What I've done is adding an attribute which gets set to True in __init__() and False by the @reconstructor - a more complete implementation would probably want to reset the flag to False on objects which are alive when a transaction commits, but my use case does not need that complexity.
-----Original Message----- From: sqlalchemy@googlegroups.com [mailto:sqlalchemy@googlegroups.com] On Behalf Of Simon King Sent: 11 August 2016 10:33 To: sqlalchemy@googlegroups.com Subject: Re: [sqlalchemy] Tracking instance commit status 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 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. -------------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By communicating with Morgan Stanley you consent to the foregoing and to the voice recording of conversations with personnel of Morgan Stanley. -- 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.
