Re: [sqlalchemy] Sending queue messages/emails after model commit
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 ale...@tictail.com 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 sqlalchemy+...@googlegroups.com javascript:. To post to this group, send email to sqlal...@googlegroups.com 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 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.
[sqlalchemy] Sending queue messages/emails after model commit
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.
Re: [sqlalchemy] Sending queue messages/emails after model commit
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.
