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.
