for some majority of Django developers?
Thanks!
--
Steven
On Mon, Oct 17, 2011 at 10:02 PM, Steven Cummings wrote:
> Well, per discussion so far I've rolled the changes back [1] to simply
> ensuring that the low-level query objects return usable counts. There was
> discussion of w
Right, let me rephrase that as just Model.save(), Model.delete(), &
QuerySet.delete()
--
Steven
On Sat, Nov 26, 2011 at 3:37 PM, Florian Apolloner wrote:
> Hi,
>
>
> On Saturday, November 26, 2011 9:42:38 PM UTC+1, Steven Cummings wrote:
>>
>> So, what are core-de
Okay, that's good stuff. So make the QuerySet APIs consistent
(delete/update should return the same sort of info) but leave Model alone
entirely.
--
Steven
On Sat, Nov 26, 2011 at 3:58 PM, Florian Apolloner wrote:
> I think it would be great if delete would return the deleted rows (but
> only of
I'd like to propose some simple improvements to
django.views.generic.base.View:
1. To complement the automatic HTTP 405 response, provide a default
implementation of the HTTP OPTIONS method. This default response would have
an HTTP 204 NO CONTENT status and include an Allow response header just
li
On Sun, Nov 27, 2011 at 4:17 PM, Jamie Matthews wrote:
> > 2. Improve the default HTTP HEAD handler by ensuring it has a blank body,
> > as this is the expectation of a response to a HEAD request. Also, there
> > should be consideration for the GET handler not existing, which should
> > result in
I assumed I needed the votes here to get going on that. In the past when
I've started with a ticket I've been directed here to gather support first.
--
Steven
On Mon, Nov 28, 2011 at 11:59 AM, Jamie Matthews
wrote:
> > Yeah, that implementation seems preferable. What was the reason for
> backing
I'll probably go ahead and log it and start the patch soon. Your feedback
on truncation for HTTP HEAD was helpful, and the rest doesn't seem very
controversial.
--
Steven
On Sat, Dec 10, 2011 at 5:26 AM, Jamie Matthews wrote:
> Just bumping this - can anyone suggest what the next steps should be
Created a ticket with the patch: https://code.djangoproject.com/ticket/17449
--
Steven
On Sun, Dec 11, 2011 at 3:29 PM, Steven Cummings wrote:
> I'll probably go ahead and log it and start the patch soon. Your feedback
> on truncation for HTTP HEAD was helpful, and the rest doesn&
The docs around the provided CBVs and mixins are an issue, but also what is
missing is that programmers seem to still think those that are provided
should work for more cases than they probably do. When the narrative for
CBVs is documented, should Django focus on mixins and state the expected
limit
Sorry for chiming in so late. I very much like the goals of this effort,
particularly bringing clarity to some of the internal APIs. Some related
points for your consideration:
* Would the rows matched vs. updated issue be resolved or clarified in this
effort [1]?
* It seems like the work I had st
:
> On 26 kesä, 08:41, Steven Cummings wrote:
> > Sorry for chiming in so late. I very much like the goals of this effort,
> > particularly bringing clarity to some of the internal APIs. Some related
> > points for your consideration:
>
> No problem. I have been so busy
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
Bad community member that I am, I jumped the gun and logged a ticket
[1] on this one... anyway:
Websites general avoid overly aggressive locking of data to deal with
concurrency issues. When two users allowed to edit some data are
simultaneously doing so, they're both allowed to do so and the
last
and cas) to handle this
> kind of thing? It might get pretty elaborate, but with just a cursory
> thought seems doable.
>
> -peter
>
>
> On Sat, Aug 6, 2011 at 9:59 PM, Steven Cummings wrote:
>
>> Bad community member that I am, I jumped the gun and logged a ticket
>
40 AM, akaariai wrote:
> On Aug 8, 4:54 pm, Steven Cummings wrote:
> > Interesting feature I hadn't noticed in memcached. That does seem like it
> > would do the trick where memcached is being used. I think the ability to
> > control it in Django would generally still be
ate/delete signals if nothing was changed
>From there you could implement fields as you see fit for your app, e.g.,
version=IntegerField() that you use in a precondition.
--
Steven
On Mon, Aug 8, 2011 at 3:57 PM, akaariai wrote:
> On Aug 8, 6:30 pm, Steven Cummings wrote:
> > For
On Thu, Aug 11, 2011 at 11:14 AM, Simon Riggs wrote:
> IDEA 2
> (1) SELECT data & version
> (2) UPDATE data & test version & COMMIT immediately
>
This is pretty much where I started when I initiated the ticket and thread
and still am at. The other discussion here is what happens when the test
fa
On Thu, Aug 11, 2011 at 12:06 PM, Steven Cummings wrote:
> On Thu, Aug 11, 2011 at 11:14 AM, Simon Riggs wrote:
>
>> IDEA 2
>> (1) SELECT data & version
>> (2) UPDATE data & test version & COMMIT immediately
>>
>
> This is pretty much where I star
Finally got around to these simple changes:
*
https://github.com/estebistec/django/commit/b48a87afc324f5546b6654fa7638e406b397c0d6
*
https://github.com/estebistec/django/commit/28ace32980b370fd17ae35019bfe8d055c673684
If the core devs approve of these changes I can get to work on creating the
pro
It is for now, but the ticket I'm building up to [1] is that it may actually
be 0 if a precondition is not met. This is how your code can know if the
current request really got to do a save or delete if two or more are trying
to update the object at the same time.
[1] https://code.djangoproject.co
--
Steven
On Wed, Oct 12, 2011 at 5:37 AM, Johannes Dollinger wrote:
>
> Am 12.10.2011 um 03:35 schrieb Steven Cummings:
>
> Ticket #12086 is a duplicate. I don't think QuerySet.delete() should return
> the number of all collected objects, but just the number of ob
--
Steven
On Wed, Oct 12, 2011 at 8:07 AM, Anssi Kääriäinen
wrote:
>
> Model.save() should return models.UPDATED or models.INSERTED. That is
> more helpful than the 1/0 return value. For example you might want to
> do different things if the model was inserted or updated in
> application code. O
On Wed, Oct 12, 2011 at 9:35 AM, Anssi Kääriäinen
wrote:
> On Oct 12, 4:47 pm, Steven Cummings wrote:
>
Then there is the possibility that some day we could support the
> UNCHANGED return value. This would be actually cheap to do if Django
> would support update of only change
On Wed, Oct 12, 2011 at 11:51 PM, Anssi Kääriäinen
wrote:
>
>
> My point is that we should never just return 0 if there is a
> concurrent modification or some other reason for not being able to
> persist the object state. Why? When you request obj.save() you are
> requesting the object state to be
On Thu, Oct 13, 2011 at 1:06 AM, Anssi Kääriäinen
wrote:
>
> Now I have the feeling that I have gone through this exact same
> discussion before, and have had the exact same misunderstanding, too,
> before. So, sorry for that...
>
It's cool. Better to make sure we're all clear here on the differen
Any opinions from core devs before I go back and make adjustments, or are
some waiting to see the patch before weighing in?
--
Steven
On Thu, Oct 13, 2011 at 11:48 PM, Steven Cummings wrote:
> On Thu, Oct 13, 2011 at 1:06 AM, Anssi Kääriäinen > wrote:
>>
>> Now I have the f
es on
base Model for now.
[1]
https://github.com/estebistec/django/commit/f178b72af132dd1ba588b89fe6915f5e9ba841d0
--
Steven
On Sun, Oct 16, 2011 at 4:48 PM, Steven Cummings wrote:
> Any opinions from core devs before I go back and make adjustments, or are
> some waiting to see the p
27 matches
Mail list logo
