Hey,

I'd like some help regarding nested session usage please.

I'm working on an application that has an API layer but also has a lot of 
cron jobs (via Celery) and scripts. I'm trying to design the app in a way 
that my "business" logic is contained and re-usable by any of these 
interfaces. 

The SQLAlchemy session scope is request/task-wide (i.e requests and tasks 
remove the scoped session at the end) but I am doing explicit commits 
instead of committing on request end because I sometimes have to deal with 
complicated logic like creating/submitting transactions to payment 
processors etc. 

To start off, I use a context manager, much like the docs, which commits or 
rollbacks as necessary. I then have a layer of actions, which are 
considered "top-level" functions that can do a simple operation e.g update 
something or a collection of operations i.e create and submit a 
transaction. These actions use the context manager above to persist stuff 
and I've opted to keep all session "usage" in these actions alone and 
nowhere else in the code. Pretty soon, the need to use some of the simpler 
actions inside other, bigger actions arose which, after reading the docs, 
led me to turn autocommit=True and use session.begin(subtransactions=True). 
Note that I don't want to use savepoints, I just want to be able to use my 
actions inside other actions. The docs recommend that expire_on_commit is 
set to False with autocommit, which I've done but that led to a couple of 
situations where I was operating on out-of-date data hence I want to turn 
expire_on_commit to True again. 

My questions:

(1) Does my application layout make sense from a SQLAlchemy perspective? 
(2) What is the problem with expire_on_commit=True and autocommit=True?
(3) I feel that, even with the context manager, the transaction boundaries 
are still blurry because the developer does not know what will actually get 
committed in the database. For example, if a previous part of the code 
changed something, then called an action that commits the session, the 
previous change will get committed as well. I've searched around and found 
this: https://github.com/mitsuhiko/flask-sqlalchemy/pull/447 which 
basically issues a rollback on entering the context manager to ensure that 
only what is within the context manager will get committed. What do you 
think of it? I can immediately see a problem where if I query for an object 
before passing it to an action, then use the context manager, all the work 
done on querying is lost since the object state is expired on rollback. 

I'd appreciate any advice/input.

Best,
Alex

-- 
SQLAlchemy - 
The Python SQL Toolkit and Object Relational Mapper

http://www.sqlalchemy.org/

To post example code, please provide an MCVE: Minimal, Complete, and Verifiable 
Example.  See  http://stackoverflow.com/help/mcve for a full description.
--- 
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 https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.

Reply via email to