On Oct 13, 8:33 am, Steven Cummings <estebis...@gmail.com> 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 being used to being with. I don't think this is going
> to result in the accidents you're describing, because until there is a
> specific feature context, save will return 1 (or whatever else we decide).
> I've no intention of introducing implicit features or pitfalls.Ok, so if this is going to be low level API only, then this isn't as dangerous as I though. Still, even in this case, an exception wouldn't be any worse IMHO. You could always do try: obj.save() except ConcurrentModification: pass. 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... > I think a reasonable option to discuss might be leaving the save() API as it > is and rolling this enhancement back to the internal code (i.e., > UpdateQuery, DeleteQuery) returning counts to support the prospective > enhancements I've alluded to, and/or overrides of save(). Until there are > any changes to save(), I agree it is not going to be useful info. However > for delete it seems immediately usable (and then we're left with the debate > of counting immediate-only or including related objects). I would go with immediate only, with the ability to get the counts for cascaded deletes per object type as a kwarg option. The kwarg option could be left for later implementation. One reason for immediate only is that at least PostgreSQL and MySQL does it that way for ON DELETE CASCADE foreign keys. So, if you are getting the value from the cursor and using ON DELETE CASCADE instead of doing the cascade in Django, you will not get the cascade counts anyways. And even if you do the cascade in Django, then it would be consistent with what a SQL database would report. - Anssi Kääriäinen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
