On Wed, Nov 29, 2017 at 11:14 AM, Michael Elsdörfer
<elsdoer...@gmail.com> wrote:
> So, I've been a very happy user of SQLAlchemy over many years, though maybe
> not very deeply. I certainly don't really feel qualified to contribute any
> thoughts on it's design, but I did want to bring this up, since it's
> something I have run into again and again.
>
> I'd say that in the majority of projects that involve SQLAlchemy, sooner or
> later I find myself in a situation where I want to work with database
> objects that I don't want to save to the session. It's just so damn
> convenient to pass them around.
>
> Here are two examples off the top of my head:
>
> - A billing tool was supposed to generate a bunch of objects (line items and
> so on); in preview mode, I want to use the same functions to calculate and
> generate the objects, and serialize them to the browser, but I don't want to
> save them.
>
> - In a system to check if the user has the permission to "add an object", I
> really wanted to construct the object temporarily, unsaved, and send it to
> the permission-layer, but without adding it to the session.
>
> Now often, what I do to solve this is what I think SQLAlchemy wants me to
> do, if I understand correctly: Configure the cascades on the relationships
> accordingly. But this has some problems:
>
> 1) It's *really* hard. Each time I find myself going back to the
> documentation, and trying to figure out where stuff needs to be changed
> (what does cascade_backrefs on a backref() mean again?)
>
> 2) It's error prone. It's easy to later pull in an object through some other
> relationship; it's also hard to later figure out exactly why the cascades
> where configured in the way that they are, and which code paths depend on
> that particular cascade setting. Changing any cascade may easily cause side
> effects that are not predictable.
>
> So thinking about it, changing the cascade settings on the relationship is
> not really what I want to do. What I really want: The cascade to work in
> most cases, *except this one time*. I find myself searching for a version of
> `session.no_autoflush`. For example:
>
> with session.no_cascade:
>    order = Order()
>    order.account = current_account
>
> Since current_account is in the session, the order would ordinarily be
> pulled into it, too. But the decorator could prevent that.

you mean the context manager, sure.

this is actually not a bad idea, at least in some contexts.   I'm not
sure folks would really understand this API very often, but you do and
I know what you want, sure.

I'd have no_cascade be more of a function so that it allows some configurabilty:

with session.no_cascade("save-update", Order)    with
session.no_cascade("all"), something like that.   you'd want to be
able to limit it to the type of cascade and the type of object for it
to be generally useful.

it's *mostly* feasible sure, because the Session is the thing that
actually invokes the cascade of things which occur.   However some
cascades don't occur until a flush later on, most notably "delete" and
"delete-orphan" cascade, so im not sure this context manager is that
useful for that kind of thing unless you were using it for a broader
block of operations (hence the arguments I proposed).   If you were to
block off current_account from being added in the first place, this
would be all you need.

I know that save-update is the one you really want, and it's also the
easiest to accomplish, so some thought would have to be put into how
best to present such a feature.     Perhaps some
session.dont_cascade_adds or something more limited like that.   not
sure.



>
> Or maybe:
>
> from sqlalchemy import taint_no_cascade
> order = Order()
> taint_no_cascade(order)
> order.account = current_account
>
> The whole thing is probably much more complicated than that, but I desire
> this so frequently, I wanted to ask if it's feasable, or has been discussed
> before.
>
> Thanks,
>
> Michael
>
> --
> 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