On Wed, Aug 9, 2017 at 4:26 PM, Mike Bayer <[email protected]> wrote: > made. Which is above, **if you are not using begin() and commit(), > the way we just said you should, then you should turn off > autocommit=True**.
arg arg ARG ARG "if you are **not** using begin() and commit(), and are instead just calling flush() which fully commits, then you should **disable** expire_on_commit=True, to avoid excessive re-loads of data." That section needs another rewrite but then again > the entire concept of "subtransactions" also needs to be discouraged > as these are all obsolete patterns. > > >> (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. > > So this whole part sounds wrong. If you want your database function > to occur in the context of a larger transaction, then by definition, > there may be other pending data present. Whether that data is pending > in the session of your Python application, or pending in the MVCC > buffer of your database, doesn't matter from a transaction-level point > of view. It might matter for performance or debugging reasons, but in > that case, you'd want to just emit flush() at the top of the block, so > that those pending changes are on the server side of the transaction > rather than the client side, but all of it is still pending as far as > being permanent to disk and visible to the rest of the world. > > if you have a function that wants to persist data out to the database > and it does not want to persist data that is already pending in the > ongoing tranasction, it should use a separate transaction. This is > a common use case and it is what you do if you are for example putting > rows into a job queue type of table, or sending out messages that are > going to show up in some log or console output somewhere. > > >> 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'm much more a proponent of writing one's own patterns that suit > their application rather than making the prepackaged ones in something > like Flask fit. I think if it implicitly rolls back, that's a > terrible idea because if you truly expect that nothing important is > present in the session, it should be asserting that and raising if > something is found (look in session.new, session.dirty, > session.deleted). > > > > > 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/sqlalchemy. >> For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
