Hi Alex, I have a similar use case, and fixed it by buffering the signals until the session transaction completes. On rollback, the buffered signals are discarded; on successful commit, the signals are truly emitted.
Cheers, Jason On Mon, Sep 22, 2014 at 2:20 AM, Alex Michael <alex...@tictail.com> wrote: > Hey, > > From my understanding it's recommended that the business logic does not > commit the session and that the application itself handles the session > lifecycle. Following that, I have all the session handling logic in my > controllers so the business logic just changes the objects as necessary and > then the controllers call .commit() when needed. When a model is committed > and say X property has changed, I need to send a queue message. My problem > is that I'm not sure where the logic for emitting such signals should live > in order to avoid duplicating logic all over the place. An example: > > I have an order which I take a payment for. If the payment is successful, > I mark the order as paid. At this point I need to emit a signal. If the > order is pending, I wait for a notification to come in from the payment > gateway and then mark the order as paid. My business logic has a > `mark_as_paid` function which changes the status of the order. Ideally I > would like to emit the signal in the `mark_as_paid` method but I don't know > at that point in time if the session commit will succeed or not. The > alternative would be to emit the signal manually after the session was > committed but that would (1) lead to duplicated logic since `mark_as_paid` > can be triggered from many code paths (2) not always work since the status > of the order is determined dynamically so the caller doesn't actually know > what "changed" in order to emit the correct signal. > > Am I missing something here? I'd appreciate any help. > > Thanks! > > -- alex > > -- > 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/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 http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
