On Sat, 20 Nov 2021 at 14:21, Florian Apolloner
wrote:
> I even have a possible fix for that, but it requires us to rewrite
> middlewares again :/
>
This is the third time this has come up (the middleware rewrite I mean)
Rule of Threes. We need a DjangoCon, so we can draft a DEP. :)
>
--
You
Hi Aymeric,
On Saturday, November 20, 2021 at 12:39:17 PM UTC+1 Aymeric Augustin wrote:
> I'm not trying to disagree for the sake of disagreement; I'm just trying
> to bring some contextual awareness and avoid the "core devs say
> ATOMIC_REQUESTS is bad" effect. I hope we can agree on this?
>
Hello,
> On 18 Nov 2021, at 11:11, Florian Apolloner wrote:
>
> FWIWI I always recommend disabling ATOMIC_REQUESTS and using transactions as
> needed :)
Investing engineers' time into evaluating the exact transactional integrity
requirements of every view may be appropriate
On Wednesday, November 17, 2021 at 11:09:58 PM UTC+1 Adam Johnson wrote:
> FWIW I always recommend enabling ATOMIC_REQUESTS and ensuring transactions
> are used by default in other code paths such as background tasks.
>
FWIWI I always recommend disabling ATOMIC_REQUESTS and using tra
Hi Adam
I will check into it.
IMO using ATOMIC_REQUESTS is an antipattern. Views shouldn't know anything
about the database. Services should handle all persistence related stuff
and that's why transactions should only be used when necessary.
Best!
Klemen
sreda, 17. november 2021 o
e check in
select_for_update(), and perhaps other things that require an atomic()
(i.e. they check connection.in_atomic_block). You could investigate if a
patch is feasible.
FWIW I always recommend enabling ATOMIC_REQUESTS and ensuring transactions
are used by default in other code paths such as backgr
Hi!
I noticed dangerous behaviour with testing and usage of *select_for_update *in
transactions.
This "feature" crashed some parts of production in our company.
The "feature" I am talking about, is that test runner wraps all tests in a
transaction. If you use *select_for_upda
Christian, FYI you can do this already for all new connections with
something like this in an apps.py:
from django.db.backends.signals import connection_created
@connection_created.connect
def transactions_readonly(*, connection, **kwargs):
with connection.cursor() as cursor:
cursor.e
Hello Simon and Christian,
good point, making a particular connection read only would be even better
than using a modified atomic.
This way, if I really do need to use a read only transaction, I could just
simply wrap my view inside an atomic decorator like
@transaction.atomic(using='readonly')
Am 01.07.20 um 20:28 schrieb charettes:
Do you think that allowing a readonly boolean flag[0] to be specified
in OPTIONS per connection like we do for isolation level[1] could work
for your use case? From my experience this particular problem is
usually dealt with by using database routers
set_session
Le mercredi 1 juillet 2020 à 08:56:43 UTC-4, Andor a écrit :
> Greetings Django developers,
>
> I'd like to explicitly declare some of my database transactions as read
> only to enable certain optimizations, but after inspecting the
> documentation, forums and so
Greetings Django developers,
I'd like to explicitly declare some of my database transactions as read
only to enable certain optimizations, but after inspecting the
documentation, forums and source code, it seems this feature is missing.
As far as I understand,
https://docs.djangoprojec
As MIDDLEWARE supports decorator-like objects you could simply add
`django.db.transaction.atomic' to it and you'd get each request wrapped in
a transaction.
Note that this will only start a transaction on the `default` database,
just like the old TransactionMiddleware use to do.
Simon
Le merc
Starting with Django 1.10 you can write a TransactionMiddleware again, and
we will probably ship one again.
On Tuesday, May 10, 2016 at 2:07:30 AM UTC+2, Kevin Tran wrote:
>
> Thomas, did you ever find a solution to your problem? I'm having similar
> thoughts and am looking for an answer.
>
> O
Am Dienstag, 10. Mai 2016 02:07:30 UTC+2 schrieb Kevin Tran:
>
> Thomas, did you ever find a solution to your problem? I'm having similar
> thoughts and am looking for an answer.
>
>
Carl Meyer has worked out an enhancement proposal, here is the
pull-request: https://github.com/django/django/
Thomas, did you ever find a solution to your problem? I'm having similar
thoughts and am looking for an answer.
On Friday, February 6, 2015 at 4:18:53 AM UTC-8, guettli wrote:
>
>
>
> Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen:
> > I'd really like to be able to define middlewares that actu
Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen:
I'd really like to be able to define middlewares that actually work in
a well defined and easy to use way. Currently, there is no
guarantee(!) that either process_exception or process_response gets
called after process_request has been called for
I'd really like to be able to define middlewares that actually work in
a well defined and easy to use way. Currently, there is no
guarantee(!) that either process_exception or process_response gets
called after process_request has been called for given middleware, and
this makes it impossible to im
On Wednesday, February 4, 2015 at 10:53:28 AM UTC+1, guettli wrote:
>
> Will a patch to provide settings.MIDDLEWARES_INSIDE_TRANSACTION be
> accepted?
>
Most likely not since one of the reasons why @atomic isn't applied via a
middleware (which would then include the middlewares after it) is t
the database. Database queries that run at every
request aren't good for overall performance.
4) For lack of a better reason, keeping the database transactions short is more
efficient.
1) and 2) really boil down to the fragility of how Django executes middleware.
Not including middleware in
at happens.
3) Most middleware don't touch the database. Database queries that run at
every request aren't good for overall performance.
4) For lack of a better reason, keeping the database transactions short is
more efficient.
1) and 2) really boil down to the fragility of how Django exec
that each view function needs to be decorated potentially n times.
We understand that transactions might effect performance, thus lesser transactions being in a transaction means faster
execution. However, shouldn't there be the possibility to include distinct middlewares into the
Hello,
Like its predecessors `commit_on_success` and `xact`, `transaction.atomic`
doesn't guarantee atomicity if the connection gets closed in the middle of the
transaction. Django automatically reopens it and proceeds happily, losing the
first half of the transaction and saving only the second
On Saturday 28 September 2013 12:24:22 Aymeric Augustin wrote:
> On 28 sept. 2013, at 11:56, Shai Berger wrote:
>
> > If Option 2 is to be viable, it needs to be modified to store the original
> > problem and its traceback, and add them to the errors somehow. On Python
> > 3,
> > exception chaini
On 28 sept. 2013, at 11:56, Shai Berger wrote:
> Just a note -- option 2 has the potential (like PostgreSQL's error handling)
> to hide the problems and make them very hard to debug. Consider a site using
> ATOMIC_REQUESTS (equivalently, TransactionMiddleware) on a
> statement-atomicity
> dat
x27;t related to
> the database, it's possible to run queries. However, their effect will be
> lost during the final rollback at step 5. Developers may be surprised by
> this rollback. It doesn't break the fundamental contract of `atomic`
> (atomicity) but it's unexpected.
>
it's unexpected.
This is clearly an abstraction leak: `atomic` manages database transactions
through Python exceptions, but the two can get out of sync. Technically, it can
be traced to the `savepoint=False` option of `atomic`, but that's a red
herring, and I don't think we can do m
Hello,
I'm using Django since a couple of years and the more I use it the
more I wish a support for django-managed nested transactions.
I think in complex programs often happens to need them.
So I would post here my own source code of such tool, based of Django
1.3
commit_on_success().
A
cases, combined
>> with the side effects of having dangling connections and transactions
>> might almost be enough to convince me that can invoke the bug clause
>> to break backwards compatibility. If you (or anyone else) has any
>> opinions on this, I'd be intereste
On Dec 21, 2010, at 11:39 AM, Jacob Kaplan-Moss wrote:
> Unless there are objections, I'm going to accept this approach and
> check in a change based on Shai's latest -bugfix patch.
FWIW, +1.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed t
n
> break backwards compatibility to correct behavior that is clearly
> wrong. I haven't fully thought through the consequences here, but I
> think the combination of the footprint of affected cases, combined
> with the side effects of having dangling connections and transactions
>
Hi all,
This is just to let you know that, assuming interested parties have been
notified, I'm taking the discussion back to the bug where it belongs (and
patches can be added).
Thanks,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django develop
l me
> with joy. Code that works today must work tomorrow, however
> inconvenient it is to accommodate. The fact that Django's own test
> suite needs modifications in order to pass sends up a warning flag for
> me -- if our test suite needs modifications in non-obvious places
> (i.e.,
ombination of the footprint of affected cases, combined
> with the side effects of having dangling connections and transactions
> might almost be enough to convince me that can invoke the bug clause
> to break backwards compatibility. If you (or anyone else) has any
> opinions on this, I&#x
On Mon, Nov 22, 2010 at 6:03 AM, Shai Berger wrote:
> Hi list,
>
> #9964 is about managed transactions not being committed under transaction
> middleware (or transaction.commit_on_success decorator) after the database was
> modified via raw SQL. The root cause of that is that,
Hi Shai and list,
I tested your patch with my applications. All my unittests pass.
Shai Berger wrote:
> Hi list,
>
> #9964 is about managed transactions not being committed under transaction
> middleware (or transaction.commit_on_success decorator) after the database
> was
>
Hi list,
#9964 is about managed transactions not being committed under transaction
middleware (or transaction.commit_on_success decorator) after the database was
modified via raw SQL. The root cause of that is that, today, managed
transactions only become "dirty" when there is clea
On Fri, Mar 12, 2010 at 9:50 AM, orokusaki wrote:
> @James Bennett I was suggesting a new feature. Is it still not
> appropriate?
It still is not appropriate, and it's not hard at all to see why:
*ANY* question which begins "How do I do this in Django" belongs on
the django-users list, even if yo
@James Bennett I was suggesting a new feature. Is it still not
appropriate?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email
This message is inappropriate for this list. Before sending mail to
Django discussion lists in the future, please read up on the
difference between the django-developers list and the django-users
list.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--
You re
First, here's the problem I'm having, and then I'll bring up my
request. I have a model that looks like this (using dev version):
class SecretModel(models.Model):
some_unique_field = models.CharField(max_length=25, unique=True)
# Notice this is unique.
class MyModel(models.Model):
secret_
Isn't it TRANSACTION_MANAGE = True?
Ben
On 2 Nov, 17:19, Jacob Kaplan-Moss wrote:
> On Mon, Nov 2, 2009 at 11:27 AM, Ben Ford wrote:
> > I'm really curious though -- can anyone remember far back enough to
> > know where this came from? I haven't been able to find a single
> > mention of DISABL
On Mon, Nov 2, 2009 at 11:27 AM, Ben Ford wrote:
> I'm really curious though -- can anyone remember far back enough to
> know where this came from? I haven't been able to find a single
> mention of DISABLE_TRANSACTION_MANAGEMENT anywhere in django's
> history!
I'm pretty sure this is a document
Hi All,
I'm looking into the transaction module due to an app that I'm working
on doing something very odd (and mostly indefensible) with long
running transactions.
It would seem that the docs are totally off base WRT to transactions -
specifically the DISABLE_TRANSACTION_MANAGEME
On Mar 20, 6:29 pm, "Moof" <[EMAIL PROTECTED]> wrote:
> Well, I decided to try getting django running on my box, with SQL
> Server 2005 Express, and it fails abysmally.
OK, so I can't read ado_mssql errors correctly. It's not the lack of
comments_comment that's the issue, it's the foreign key
Well, I decided to try getting django running on my box, with SQL
Server 2005 Express, and it fails abysmally.
I discovered patch #2358. Elsewhere on the list, people claim it
works, but using the latest SVN head, it doesn't even manage to run
the test suite.
I decided to give it a bit of a go,
e
Not everybody will use the django code in webapps - if you write batch
programs, you need a way to do transaction handling, too. And the
decorators already "stack" - you might have the transaction middlware
active, so your transactions are bound to request/response, but you
want to us
[EMAIL PROTECTED] wrote:
> ... transaction support, its the biggest thing stopping me from using
> django for production work.
Me, too. I'd like to use Django for a time and expense app, but it's a
no go without some kind of answer for bootstrapping transactions into
my code.
-jason
Hi,
>Maybe it would be easier to discuss this with some code at hand. If
>#616 would be applied, django would have the needed "process_exception"
>mechanism (that would be usefull regardless wether we use it for
>transactions or not, I think). Then I could hack up the mid
fwiw the zope transaction implementation supports save points from data
managers that support it. the postgres impl currently doesn't but it
would be straightforward to make it so.
cheers,
-kapil
register with the transaction and recieve transaction
messages, in a django context, a database connection wrapper would be a
data manager. because the dbapi specifies transactions on a connection
level, at implementation level, you'd need multiple database
connections to achieve your go
the transaction patch didn't couple the transactions exclusively to the
web layer, with it you can use a python script or interactive
interpreter, via the api provided by the transaction manager. ie.
import transaction
# do some work
# and
transaction.commit()
# or
transaction.
problems with python for years. the patch
itself is small, in part due to the functionality of the libraries z3
offers, and the nice design of django, but more importantly in addition
to making django transactional it provides a solid foundation as well
for future work with transactions in djan
>Great; is decorator_from_middleware implemented or still an idea? I
>can't find it mentioned in the docs.
from django.utils.decorators import decorator_from_middleware
from django.middleware.middlewaremodule import MiddlewareClass
decoratorfunc = decorator_from_middleware(MiddlewareClass)
:-)
it would be easy to toggle between the two. (As you
say below, code would make all of this easier. :) )
# This discussion is titled "transactions in the admin" - there you
# usually don't have those out-of-band activity, you only have the
# all-or-nothing-approach. The middlew
ure: in those cases you just won't use the "easy-way-out" middleware,
but just use the "disable-commit-on-save" machinery and do explicit
commits and rollbacks yourself.
This discussion is titled "transactions in the admin" - there you
usually don't have those
more to do with the content
itself than does the transactionality of the request. That's what
inspired the comment.)
# The nice thing about using a middleware for binding transactions to
# the request would be that the transaction stuff won't be coupled
# with the request machinery
eware already has side-effects like changing elements of the
request object, for example. Or storing stuff in the cache - the
caching middleware actually would be a much "bigger" middleware than
the transaction middleware :-)
The nice thing about using a middleware for binding transactions to
# So we can't just pass cursors around and let users decide what
# cursor to commit - the commit would have to be on the
# connection. And it would commit all open database changes, even from
# cursors the user didn't really know about.
But *are* cursors being passed around? I guess I'm assuming
# I think the best way to do commits is to tie them to the request by
# using a middleware that does the commit-rollback-handling. Only
# needed change to django would be a process_exception middleware hook
# that is only triggered if the viewfunc throws an exception - to do
# the automatic rollba
>But my point was that transactions shouldn't *have* to be tied to Web
>requests. We should be able to use transactions outside the scope of a
>Web request -- in, say, a Python script or the interactive
>interpreter. Transactions shouldn't be coupled with any other layers
&g
x27;s in a different
abstraction plane now.
Additionally admin code should be modified to use it.
Thanks,
Eugene
"Jonathan Daugherty" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
>
> # We should be able to use transactions outside the scope of a Web
> #
Jonathan Daugherty wrote:
# We should be able to use transactions outside the scope of a Web
# request -- in, say, a Python script or the interactive
# interpreter. Transactions shouldn't be coupled with any other layers
# of the stack.
I agree. It seems to me that "transacti
# We should be able to use transactions outside the scope of a Web
# request -- in, say, a Python script or the interactive
# interpreter. Transactions shouldn't be coupled with any other layers
# of the stack.
I agree. It seems to me that "transaction support" doesn't need
On 10/11/05, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> >I haven't tested the patch to #9, but it requires (at least part of)
> >Zope, which is a big reason not to use it. Also, I don't know whether
> >coupling transactions to Web requests is a good id
I haven't tested the patch to #9, but it requires (at least part of)
Zope, which is a big reason not to use it. Also, I don't know whether
coupling transactions to Web requests is a good idea.
Think of it from the perspective of an inline form. If I have a single
form that is ass
Also, I don't know whether
coupling transactions to Web requests is a good idea.
Anybody have ideas on implementations? Let's get this going.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
Hello folks,
I'm interested to know about the status of transaction support in
general, with particular regard to the admin interface and inline
editing. I see that there was once a short thread started by Kapil,
the submitter of a patch to implement transaction support in ticket
#9.
(Google gr
68 matches
Mail list logo
