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 think it would be great if delete would return the deleted rows (but only
of the base table obviously), -1 on model.save() returning a rowcount.
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on
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-dev thoughts on going on ahead and
Hi,
On Saturday, November 26, 2011 9:42:38 PM UTC+1, Steven Cummings wrote:
>
> So, what are core-dev thoughts on going on ahead and returning
> row-modified counts from Model.save() and QuerySet.update/delete?
>
QuerySet.update already returns the modified row count.
Cheers,
Florian
--
You r
I'm assuming there's some more work to do here, but I was hoping to get
opinions from core devs on what's been discussed so far. Some of the
feedback above was that because save() can only return a rows-modified
count of 1 right now, that it's silly to even change. So the tentative
decision is simp
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 whether delete should return counts for immediate objects only
or related as well, but I further decided to simply impose no API changes on
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 feeling that I have g
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
On Oct 13, 8:33 am, Steven Cummings wrote:
> So the situation I expect this to occur in is the context of very deliberate
> coding by the programmer, e.g.:
>
> count = obj.save(where={'version': 1})
>
> If the programmer forgets to check the count then they probably didn't
> understand the feature
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 Oct 13, 5:40 am, Steven Cummings wrote:
[About the 1/0 return value of .save()]
> Well, obviously I hope it does have use in the original ticket that spawned
> this one. I guess what I might need some help with here is: what are some of
> the directions of the ORM that might affect this decisio
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 changed fields. We couldn'
On Oct 12, 4:47 pm, Steven Cummings wrote:
> If you're ensuring a set of data from some other source, what's the use of
> knowing what was new? Are there other concrete cases where this might be
> useful?
The standard use when synchronizing data is to make sure there aren't
too many changes. This
--
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
--
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 objects deleted
> from QuerySe
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
On Oct 12, 1:37 pm, Johannes Dollinger
wrote:
> Ticket #12086 is a duplicate. I don't think QuerySet.delete() should return
> the number of all collected objects, but just the number of objects deleted
> from QuerySet.model.
Agree. A way to get the counts per object type would be useful
(loggin
Am 12.10.2011 um 03:35 schrieb Steven Cummings:
> Finally got around to these simple changes:
>
> *
> https://github.com/estebistec/django/commit/b48a87afc324f5546b6654fa7638e406b397c0d6
> *
> https://github.com/estebistec/django/commit/28ace32980b370fd17ae35019bfe8d055c673684
>
> If the core
Uhm question -- Does the count for Model.save() make any sense? Isn't that
always one?
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-develo
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
20 matches
Mail list logo
