> I think that patch was just an example of bad abstraction. For instance,
_log_and_response was strange and confusingly named, and seemed to be there
mostly for vanity, to mask the imperative nature of the top level of
control.
Proposed patch author here. Yes, I agree that wasn't a very successfu
Hmm if we're going down that path, I'd prefer to be more explicit about it.
How about including the exact command that people can copy to re-run the
failed test?
This is what the RSpec library (a Ruby testing library) does, and IMO it
really gets it right.
See this blog post here from a Ruby core
I would also love to see this in Django. Although I mostly use Postgres, it
would be nice not to be locked into a single database vendor if I were to
use a JSONField.
On 23 Jun 2016 7:57 PM, "Raphael Hertzog" wrote:
> Hello,
>
> in almost all projects I work on, I end up using a JSONField. Since
Hi all, I'd like to bring up ticket
#26706: https://code.djangoproject.com/ticket/26706
Related managers have methods such as add(), change() and remove() that
change database objects. When a prefetch_related is done prior to calling
these methods, it does not clear the cache. When the related
BTW, if I understand your problem correctly you might be able to do this
using a subquery:
non_special_items = Item.objects.exclude(id__in=special_items)
special_only_bundles = Bundle.objects.exclude(items__in=non_special_items)
On Thursday, May 19, 2016 at 11:19:42 PM UTC+10, David Xiao wrot
> If there is an easy answer, one using a single query, please let me know.)
Can you post what your desired SQL would look like?
IIRC, foo.exclude(id__in=[bar, baz]) already adds "NOT IN" to the SQL query
(but I may be wrong), i.e "SELECT foo WHERE id NOT IN (bar, baz)"
So what do you propose f
Would it be better to add an optional parameter to the constructor of
JsonResponse instead of a new subclass?
On 16 Apr 2016 12:06 PM, wrote:
> Django 1.7 realease JsonResponse subclass of HttpResponse helps easily
> create JSON-encoded responses.
>
> As discussed in https://code.djangoproject.c
nd it would be more useful
> to try to move toward enhancing the forms library itself (if possible) so
> that less admin-specific code is needed. Have you thought about this at all?
>
> On Saturday, January 23, 2016 at 12:03:41 PM UTC-5, Yoong Kang Lim wrote:
>>
>> Currently t
Currently the BaseModelAdmin class has a method called
formfield_for_dbfield which has a conditional block that in turn calls
different formfield_for_* methods depending on the type of database field
it is handling. In order to do any custom logic to these fields we need to
override these metho
This seems like a huge change. If you were to include this feature in
Django, would it be straightforward for users to migrate from previous
versions?
On Sunday, May 31, 2015 at 2:52:37 AM UTC+10, Emil Stenström wrote:
>
> Hi,
>
> This is the first feature proposal as part of my general drive
10 matches
Mail list logo
