On Wed, Aug 9, 2017 at 4:26 PM, Mike Bayer <mike...@zzzcomputing.com> 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 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.

-- 
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