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 as admin_views_main
admin_views_main.MAX_SHOW_ALL_ALL
I thought Django already did option 1. If it doesn't, why not? What
are the possible edge cases? Using a date field named "date" as a
foreign key to another model that also contains a "date" field?
On May 10, 1:47 am, Ulrich Petri wrote:
> Currently there are at least 4 open tickets [1-4] that p
> These features have the stated purpose of allowing a response to be
> altered by middleware or decorators. However, if a decorator causes the
> template to be rendered, then such alterations will not happen.
>
> This is a serious issue, because decorators like these are often applied
> on an ad-
Hi Luke,
I actually faced a problem similar to this when I ported CBV from 1.3
to 1.2, and then tried to use the TemplateResponse with a couple of
middleware decorators that I created from some custom middleware
classes. If I recall properly, I was also having backwards
incompatibility problems w
On 12/05/11 00:20, Carl Meyer wrote:
> Yeah, this is bad. I don't have a lot to add at the moment, except to
> also point out #15855 - cache_page as a decorator breaks proper setting
> of Vary headers.
>
> The reason I bring it up here is just to point out another case,
> unrelated to TemplateRes
On Thu, May 12, 2011 at 3:35 AM, Shawn Milochik wrote:
> Someone on django-users just commented that they set a default value on a
> DecimalField as a float, and were surprised when they were unable to create
> a queryset using a float to find records.
>
> I searched Trac for the terms 'DecimalFie
On 05/11/2011 05:37 PM, Luke Plant wrote:
> The only solution I can see that isn't awful is providing two views - a
> default and documented one that has all the right decorators applied,
> and one that is obviously 'use at own risk', called something like
> 'login_unsafe', for which we document
On 11/05/11 20:20, Jannis Leidel wrote:
> Hi all,
>
> This is in continuation to Simon's previous efforts about adding tools
> for easy signing, including secure cookies ([1], [2]).
>
> Stephan (who is working on #9200 [3] -- improving the wizard in
> contrib.formtools) and me just updated the pa
W dniu poniedziałek, 9 maja 2011, 19:05:17 UTC+2 użytkownik SleepyCal
napisał:
>
> Hi guys,
>
> I spent literally *months* trying to find the best way to resolve this
> situation. (...)
>
Have you checked my StackOverflow answer I linked in the top post? It
*completely* removes the problem for
OK, I've thought about this a bit more, and I think we have some nasty
problems.
First, existing decorators:
1) It looks like the cache_page decorator will actually work with
TemplateResponse, but only because the cache middleware special-cases
responses with a 'render' method.
This is cheating
Someone on django-users just commented that they set a default value on
a DecimalField as a float, and were surprised when they were unable to
create a queryset using a float to find records.
I searched Trac for the terms 'DecimalField default' and didn't see
anywhere that this was brought up
On 11.05.2011, at 20:35, David Durham wrote:
> On Mon, Apr 25, 2011 at 11:09 AM, Stephan Jäkel wrote:
>> Hi everybody,
>>
>> I want to continue the discussion on the replacement of
>> django.contrib.formtools.wizard (previous discussions can be found here:
>> http://bit.ly/eI5ZT5 and http://bit.
Hi all,
This is in continuation to Simon's previous efforts about adding tools
for easy signing, including secure cookies ([1], [2]).
Stephan (who is working on #9200 [3] -- improving the wizard in
contrib.formtools) and me just updated the patch attached to ticket
#12417 [4] with the recommended
On Mon, Apr 25, 2011 at 11:09 AM, Stephan Jäkel wrote:
> Hi everybody,
>
> I want to continue the discussion on the replacement of
> django.contrib.formtools.wizard (previous discussions can be found here:
> http://bit.ly/eI5ZT5 and http://bit.ly/gVTRtr).
I keep seeing some maintenance type of a
http://code.djangoproject.com/ticket/15064
http://code.djangoproject.com/ticket/15595
Hi. Just wondering if someone could take a look at these. It's been two
weeks since the last activity, and already one of them had a merge
conflict with trunk, so I just updated it.
If there's a problem with
> You do make a good point. It's not just that NoSQL systems lack
> features (transactions, schema, relations) that are common to SQL-
> based systems
Actually most graph databases (such as neo4j) which are all considered
NoSQL, have all those features you just mentioned (ACID, relations,
schemas
On 05/11/2011 03:17 AM, Chris Beaven wrote:
3. Change lookups to be uppercase (start the process of deprecating the
current lowercase ones)
uagh, .filter(foo_CONTAINS=bar)?
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this
On Tue, May 10, 2011 at 11:29 PM, Patryk Zawadzki wrote:
> On Tue, May 10, 2011 at 9:40 PM, legutierr wrote:
>> Maybe it is inevitable that this kind of debate will crop up in any
>> discussion of django-nonrel or NoSQL, but I very much hope that the
>> philosophical debate does not detract from
18 matches
Mail list logo
