On 8/11/15 9:51 PM, Jinghui Niu wrote:
In the Documentation -- Session Basics, I read this:

        E.g. don’t do this:


        ### this is the **wrong way to do it** ###


        class ThingOne(object):

            def go(self):

                session = Session()

                try:

        session.query(FooBar).update({"x": 5})

                    session.commit()

                except:

                    session.rollback()

                    raise


        class ThingTwo(object):

            def go(self):

                session = Session()

                try:

        session.query(Widget).update({"q": 18})

                    session.commit()

                except:

                    session.rollback()

                    raise


        def run_my_program():

            ThingOne().go()

            ThingTwo().go()\



I really can't think of any reasons/risks that the above way of doing things would incur any bad consequences. Could someone shed a little light here? Thanks a lot.
1. your program will incur many tiny little transactions that each do just one SQL operation, and will lack atomicity

2. your program will make excessive use of multiple connections, often simultaneously as function A, which has its own Session, calls function B, which has its own Session, now you have two connections open in one operation, both on their own transactions, wasting resources, not sharing context, not atomic

3. the anti-pattern in #2 makes it extremely easy for deadlocks and race conditions to occur

4. your code will be littered with redundant session and transaction code which will quickly grow to be inconsistent and the code will be unmaintainable until a vast refactoring sweep goes through and fixes it (where by "fixes" it comes down to, making it look like the documentation you refer to recommends).

This is not hypothetical. I work heavily with Openstack today and large parts of Openstack suffer terribly from this antipattern and I'm trying to get them to fix all their code. See http://specs.openstack.org/openstack/oslo-specs/specs/kilo/make-enginefacade-a-facade.html for a case study and proposal I wrote.






--
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 <mailto:sqlalchemy+unsubscr...@googlegroups.com>. To post to this group, send email to sqlalchemy@googlegroups.com <mailto: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.

Reply via email to