Hey Jason, Thanks for your reply. That makes sense I guess. It just feels like this is something most webapps will need at some point and it's not as straightforward as someone would imagine.
-- alex On Monday, September 22, 2014 6:22:14 PM UTC+2, jason kirtland wrote: > > 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 <[email protected] > <javascript:>> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
