Re: A case for CASE expressions and bulk_update

I'd like to go for bulk_merge(objects, force_update, force_insert, update_fields) method. The basic implementation would call obj.save() in loop. Optimized implementations could then be added later on. Bulk update would then be an optimized implementation for force_update or update_fields cases.

Re: Template render performance

Thanks to the work Aymeric recently started, Django will have more options with regards to templating. See his DEP on Multiple Template Engines. https://myks.org/en/multiple-template-engines-for-django/dep/ Regarding changing the Django Template Language syntax for the sake of performance

Template render performance

Hello, Mostly a question, but are there any work in progress to improve templates render performance? Times when having medium to big data and/or loops get excesively high, compared to jinja2 which sadly is not as easy to use as django native template language. I would really trade a

Re: Backend-specific lookups

I just wanted to drop a line here saying "it will take me another couple of days to deal with this". On one hand, I want to wait with this for Marc's work to land. On the other, there are more urgent issues even in Oracle-land (the broken Py3 tests). And yes, I'm with Anssi on removing

to_field_allowed regressions

As some of you might have noticed the initial patch to prevent data leakage in contrib.admin via query string manipulation[1] introduced many regressions[2][3][4] that resulted in two security releases so far. The actual implementations does four checks to ensure a field is allowed to be

Re: A case for CASE expressions and bulk_update

Hi Michael, Great to see new expressions being used already! Speaking specifically about the Case structure, I think it looks nice. I was planning on writing a few functions (https://code.djangoproject.com/ticket/23753) which included Case/When of some description. My idea of a Case API was:

A case for CASE expressions and bulk_update

I've been working on a bulk_update method for a project to allow saving many instances of a Model in a single call/query, an analog to the existing bulk_create method. There seems to be some interest in this as evidenced by a library django-bulk-update

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

The reasoning for why it wasn't documented is provided here: https://github.com/django/django/pull/1443#issuecomment-28045150 On Monday, November 17, 2014 5:21:33 PM UTC+1, Carl Meyer wrote: > > Hi Alasdair, > > On 11/17/2014 09:05 AM, Alasdair Nicol wrote: > > Ticket #16986 (Model.clean

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

Hi Alasdair, On 11/17/2014 09:05 AM, Alasdair Nicol wrote: > Ticket #16986 (Model.clean cannot report errors on individual fields) > was fixed in Django 1.7, but the new feature is not documented. The > Model.clean() docs still state: > >> Any ValidationError exceptions raised by Model.clean()

Documenting reporting errors on individual fields in Model.clean (#16986)

Hi, Ticket #16986 (Model.clean cannot report errors on individual fields) was fixed in Django 1.7, but the new feature is not documented. The Model.clean() docs still state: > Any ValidationError exceptions raised by Model.clean() will be stored > in a special key error dictionary key,

Re: Request for removal: Mysql warnings get promoted to Exceptions in debug mode

On Monday, November 17, 2014 11:40:15 AM UTC+1, Aymeric Augustin wrote: > > 2014-11-17 10:45 GMT+01:00 Florian Apolloner >: > >> Imo we should make those exceptions instead! Data truncation should never >> be just a warning ;) >> > > Those who think like you can use a