I've marked the patch as ready for checkin. Instantiating fields without
any arguments for decimal field is now supported by all backends. The
format_number function has learnt to understand max_digits or
decimal_places being None. The format_number function needs review though.
When decimal_pl
FWIW, this was on my mind a few years ago and I created this [1] ticket. It
spidered out into one or two more, but the basic ideas were:
* optimistic locking could be implemented by enhancing saves with
conditions (i.e., save_if)
* a row-modified count could help that function also tell you if the
Hi Rune,
I agree with Tim. This is clearly a problem that exists, and I agree it
would be good to fix it. However, I wouldn't want to see this as an "Admin
only" fix.
I'd rather see a generic hook that Admin then leverages as the "first
customer". A similar approach was taken with object-level pe
I'm going to agree with Tim, it's a good idea but it is hard to agree on
its impact without the specifics.
On 8 December 2014 at 15:04, Tim Graham wrote:
> I am skeptical like Carl, but it seems to me the time to introduce and
> discuss this DEP is when there is an actual feature that we think c
Hi Rune,
It's not clear to me that a fix that's coupled to the admin is the way to
go when this problem could exist for any model form, etc.
One ticket you didn't mention that seems like it could be a good place to
start is https://code.djangoproject.com/ticket/16549
Tim
On Monday, December 8
I am skeptical like Carl, but it seems to me the time to introduce and
discuss this DEP is when there is an actual feature that we think could
benefit from this policy so we don't have to talk in hypotheticals.
On Monday, December 8, 2014 7:00:44 AM UTC-5, benjaoming wrote:
>
> Hi guys!
>
> As a
@Daniele
I struggled a bit with how to display the error message, and your solution
makes perfect sense.
Best,
Rune Kaagaard
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group
On Mon, Dec 8, 2014, Rune Kaagaard wrote:
>I've made a branch that adds optimistic concurrency control to the admin:
>https://github.com/runekaagaard/django-lock-the-admin/compare/adminlock. It
>works for the main change object and inlines and has tests. All tests
>passes with postgres and sql
Hi.
2014-12-08 10:41 GMT+01:00 Radek Svarz :
> Michael, Florian, I understand your remarks.
>
> Allow me to explain more.
>
> I do not advocate to replace the code by the one posted by me. I rather
> advocate to improve it.
>
> ad 1) I just react to the current implementation, where in the case o
Hi
I've made a branch that adds optimistic concurrency control to the admin:
https://github.com/runekaagaard/django-lock-the-admin/compare/adminlock. It
works for the main change object and inlines and has tests. All tests
passes with postgres and sqlite.
This prevents users from accidentally
Hi Radekm
On Monday, December 8, 2014 10:41:41 AM UTC+1, Radek Svarz wrote:
>
> ad 1) I just react to the current implementation, where in the case of
> other DBMS than PostgreSQL the hex value in 32 chars is stored. In such
> cases I propose to store it in a smaller amount of 21 characters. ( =
Hi guys!
As an external user of Django, relying on its stability, I'd like to
comment In general, I think this is possibly a good improvement.. but
possibly also a very dangerous one...
On Monday, December 8, 2014 12:38:18 AM UTC+1, Russell Keith-Magee wrote:
>
>
> On Sun, Dec 7, 2014 at 6:
Michael, Florian, I understand your remarks.
Allow me to explain more.
I do not advocate to replace the code by the one posted by me. I rather
advocate to improve it.
ad 1) I just react to the current implementation, where in the case of
other DBMS than PostgreSQL the hex value in 32 chars is
13 matches
Mail list logo
