Awesome, great suggestions both. That's a cleaner API and the implementation
itself is even slightly cleaner.
I updated the patch and uploaded it to the ticket. If you or anyone else
wants to review it and ideally move it forward, that would be excellent.
Thanks!
--
You received this message
https://code.djangoproject.com/ticket/16245
Here's the quick summary:
send_robust() as you know is a special case of send() in the signals
framework, which wraps each signal trigger in a try/except block so that an
exception in one signal doesn't prevent the rest from firing.
This is great, bu
I understand that we're supposed to suggest new features here on django-dev
first instead of opening a ticket, so here goes:
Presently in django.contrib.comments, there are two template tags that
output a list of comments:
{% render_comment_list for [object] %}
{% get_comment_list for [object]
Howdy,
I'd like to share some findings I made recently with regards to deferred
constraint checks during test runs. There's a bit of background here
(https://code.djangoproject.com/ticket/3615) and
here(https://code.djangoproject.com/ticket/11665), but this is the gist of
what's going on now:
Are any core devs interested in taking a closer look at the current patch on
this ticket (https://code.djangoproject.com/ticket/3615)? It's been through
several rounds of revision after discussion here and on the ticket comment
thread.
As of right now the patch should apply cleanly and pass tes
This issue came up again for me recently: Because the cache is not reset or
flushed after every test, cache values linger there. This can create
headaches when writing tests.
I would like to propose that we treat the cache backend(s) like database
backends during the test run. Specifically, I p
On Monday, June 27, 2011 7:04:09 PM UTC-7, Jim D. wrote:
So that caveat aside, I will try later to find a large data set I can run
> the query on to get an idea of what kind of performance hit the check
> entails. If anyone else has a large data set with two related tables, you
> c
On Monday, June 27, 2011 3:08:03 PM UTC-7, Jacob Kaplan-Moss wrote:
>
> I left some comments on the patch on the ticket.
>
Excellent just saw those. I'll take a look.
> > I'm using django-threadedcomments on a project, which has forward
> > references in one of its test fixtures, so I'm reminde
Hi all,
I spent some time last week and over the weekend nailing down a
solution for https://code.djangoproject.com/ticket/3615 . This is the
ticket about allowing forward references when loading data on the
MySQL InnoDB backend. My patch implements the proposed change
(disabling foreign key check
On May 11, 9:47 pm, Mathieu AGOPIAN wrote:
> Just to make sure i've understood the topic here: you need to change
> MAX_SHOW_ALL_ALLOWED, but only for a specific model?
>
> Otherwise you could just add something like that to, say, the root urlconf:
>
> from django.contrib.admin.views import main a
I'm looking at a five-year-old ticket here (http://
code.djangoproject.com/ticket/1342) that suggests MAX_SHOW_ALL_ALLOWED
in the admin be configurable. As of now it is hard coded at 200 in
contrib/admin/views/main.py .
The ticket is, in my opinion, somewhat erroneously marked as "fixed",
as someo
> On Sat, Jan 22, 2011 at 2:27 PM, Jim D. wrote:
> > Howdy,
>
> > I reported a bug earlier today (http://code.djangoproject.com/ticket/
> > 15144) related to a possible regression in changeset 15021 (http://
> > code.djangoproject.com/changeset/15021). The apparen
Howdy,
I reported a bug earlier today (http://code.djangoproject.com/ticket/
15144) related to a possible regression in changeset 15021 (http://
code.djangoproject.com/changeset/15021). The apparent regression is
that as of this changeset, the cache middleware no longer respects the
timeout value
Howdy,
Just wanted to see if anyone wanted to do a quick review of the patch
I submitted for #15026: http://code.djangoproject.com/ticket/15026
The ticket in question refers to a failure in contrib.session tests
when memcached is specified as the cache backend.
i had suggested clearing the cache
Cool, thanks
On Sep 20, 3:30 pm, Carl Meyer wrote:
> Thanks for your work on this! The usual Django workflow doesn't
> include patches to the mailing list: rather you can go ahead and open
> a Trac ticket and attach the patch there (even if you aren't sure of
> the approach yet), and reference t
I found some time this evening to work this out, and have included a
revised patch for this proposal at the end of this message.
I tried to keep changes to an absolute minimum, but here are a few
notes about the changes and decisions I did make:
* The addition of this feature required what I imag
Thanks for the suggestions and guidance Russ. I'll work with it a bit
more and see if it pans out.
My main concern with this working smoothly in the core has to do with
when and how application code is loaded in the process of setting up
tests. It turns out the earliest we can realistically send t
I recently asked a question on Django Users related to executing
certain code during the global setup and teardown routines that run in
Django's test runner. In my particular use case, I was looking for a
hook where I could disable some third party API code when tests
execute, in much the same way
18 matches
Mail list logo
