the before_compile event receives the Query object at the point it starts to
turn it into a SQL construct. When this happens, it's in response to having
said something like "query.all()". So there's no **kwarg that's specific to
an operation like that.
instead, when you want to send
Hello
I'd like to understand how to turn off a before_compile listener (e.g. soft
delete, to include deleted items).
For example,
I've adapted the example from the docs:
"is it better to think of rebuilding medium+ projects for 2.0 while
maintaining existing codebases for 1.3? In other words, how much will 2.0
be backward compatible with 1.3?"
I am saying the following as a general user, and not a past contributor to
this project:
As per the Release Status
Authorization is an unstructured problem. Writing code to decide who can do
what in your app can cover a broad set of cases. The most structure that
typically gets applied to this problem area is a set of if statements and
roles, but in reality, there are a lot more patterns and structure that
On Mon, Mar 1, 2021, at 9:45 AM, Ahmed wrote:
>>
> I'm not authorized to talk on behalf of F-S but IMO, these options could be
> milestones applied in parallel toward migration to 2.0. However, a question
> arises here, that you might have already seen, which is: given the major leap
> in
>
> yes so, SQLAlchemy 2.0's approach is frankly at odds with the spirit of
> Flask-SQLAlchemy.The Query and "dynamic" loaders are staying around
> largely so that Flask can come on board, however the patterns in F-S are
> pretty much the ones I want to get away from.
2.0's spirit is one
