On 01/20/2017 04:25 PM, Philip Scott wrote:
Hi Mike
Thank you for your quick and thoughtful response as usual!
so the quick and dirty approach is a flag I'm not enthused about,
nevertheless I don't plan on removing, called
_enable_transaction_accounting,
Yes I saw this when poking around in the source code - it does seem like
a bit of a backwards step; I will try and solve my problem without that :)
It's possible that if you're using the session in "autocommit" mode and
just want to occasionally "broadcast" your object state to a quick
"flush everything", that in fact turning off the "accounting" feature
with this flag is appropriate. I'm looking at this code and it really
is all about the thing you don't want, that is, anytime the transaction
goes away, erasing all the object state because we no longer know the
state of the DB.
Trying to recall why I have expire_on_commit=False but there's no
expire_on_rollback, it's because after a commit, the only thing that can
make the database state change vs. what your objects have are other
transactions outside of what you have in front of you. but with
rollback, there could have been any number of insert/update/delete
within the last transaction that are gone. The state of the objects is
going to be a combination of data that was loaded from the DB that might
have been rolled back, data that was the result of server-side defaults
and sequences from INSERT statements that might have been rolled back,
and then values that came from the application, but those values are
organized onto an object structure that itself might not exist anymore
because the transaction was rolled back. I think the idea is that to
really try flushing again, you have to start from zero when the
transaction first started and replay everything, otherwise things will
not be the same as they were before.
The more architectural answer is that the ORM considers these
objects to
be proxies for state within a database transaction.
Understood. I guess we are going a bit outside the intended SQLAlchemy
use-case here.
You can do this kind of pattern by having the ORM objects represent
the GUI state as "detached" objects, then copy the state of those
objects
into the session using a method like Session.merge.
I think this is what I will probably end up doing. There's a quite a bit
of business logic attached to the mapped classes - for example the
'Actions' are polymorphic and contain methods that are 'recipes' for
generating a standard set of steps based on the attributes of the action.
The best way would be that the GUI has its own dedicated data
structure that is distinct from your ORM model.
Yes, I think you are right here - though the business logic I described
above makes this a bit troublesome. In the past I have done this sort of
thing, created a throwaway mapped class and populated it with data so
that I could make use of its methods.
A more high-end way of representing this is to create "action"
objects which represent things the user does,
Deluxe indeed.. I'll have a think about that, though it is probably
overkill for the simple app I am writing.
Every time I do a GUI with SQLAlchemy I try a slightly different
approach - it is tantalising because each time I think I have cracked
the perfect pattern but it always ends up being slightly more
complicated than I thought! I can't come up with any suggestions on how
to do it better though.
Keep up the good work - we love SQLAlchemy at my firm. It is directly
responsible for keeping track of several billion dollars worth of
financial products and I sleep soundly at night having selected it as a
platform :)
--
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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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.
