Re: Django & memcache hashing

On Nov 20, 2008, at 05:20, Ivan Sagalaev wrote: > What concerns me is that this will break the usage of memcached > without > Django's cache API. I had the need a couple of times to do plain > instantiation of memcache.Client and work with it. If it won't see the > cache the same way as Django

Re: Proposal: Composite Foreign Keys

On Wed, Nov 19, 2008 at 19:12, David Cramer <[EMAIL PROTECTED]> wrote: > You guys are really bad about keeping on topic. :) Good way to prevent a discussion from entering Godwin-territory :) I should perhaps have mentioned something along the lines of "this is an example of where there is

Re: Post about django optimizations

l agree with david that you should at least highlight your points here. You have already corrected your post about paginator, for rest of the point you mentioned all I can say is if you had read the django book , specially chapter 20 at: http://www.djangobook.com/en/1.0/chapter20/ you probably

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

I have an idea which may solve the issue of render_to_response using a RequestContext. Why not have render_to_response as a shortcut in django.shortcuts (as it is now), and then add a 'render' method to the request instance which would do render_to_response but with a RequestContext instead. That

Re: Django & memcache hashing

Just wanted to say that we ran into this exact issue at work the other day as well. We had the C and Python versions of memcache running, and it was hashing things differently (to different servers or something as I understand it). This caused us a good couple hours of confusion. We eventually

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

On Wed, Nov 19, 2008 at 4:10 AM, Nathaniel Whiteinge <[EMAIL PROTECTED]> wrote: > > Out of curiosity, for those who want RequestContext added to > render_to_response, is there a reason you don't like using > direct_to_template instead? I see the two as being functionally > equivalent (minus the

patch review wanted (ticket #9433)

hi all, i've recently encounter a bug, submitted a ticket, was asked to solve the problem myself in an initial comment :) i submitted a patch that fix the bug, and could be potentially adapted to fix another one (see discussion in ). i didn't get

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote: ... > # Using RequestContext > def myview(request, *args): ># some code here... >request.render('template_name.html', {...}) ... > > That just seems logical to me. Rather than (potentially) break > backwards compatibility,

Explicit default managers?

Currently, "the first manager declared is the default manager". However, given the following hierarchy: --- class PublishedObjectManager(models.Manager): def get_query_set(self): return super(PublishedObjectManager, self).get_query_set()\ .filter(is_published=True)

Re: Feature reviews for 1.1

Apologies to JKM if you got this already . . . I thought I emailed you directly, but I can't find it in my sent mail folder. What happened to "integrate databrowse into admin" and a few other features? They were on the 1.1 list right before you re-organized it, so I didn't know if they were

Re: Feature reviews for 1.1

On Thu, Nov 20, 2008 at 1:38 PM, Bob <[EMAIL PROTECTED]> wrote: > Also, I added my votes here: > https://spreadsheets.google.com/ccc?key=pIaJn09D1vqW1yJjl3wGUeg > (not sure if you're counting non-committer votes or not) You're -1 on SessionWizard is partially invalid. I tried to anticipate the

DRAFT 1.1 roadmap posted

Hi folks -- I've posted a draft of the 1.1 roadmap, incorporating the feedback gathered here over the last week: http://code.djangoproject.com/wiki/Version1.1Roadmap Discuss. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to

Re: DRAFT 1.1 roadmap posted

On Thu, 2008-11-20 at 17:28 -0600, Jacob Kaplan-Moss wrote: > Hi folks -- > > I've posted a draft of the 1.1 roadmap, incorporating the feedback > gathered here over the last week: > http://code.djangoproject.com/wiki/Version1.1Roadmap > > Discuss. I'm not so sure the final phases of that

Re: DRAFT 1.1 roadmap posted

Hey Malcolm -- On Thu, Nov 20, 2008 at 6:23 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I'm not so sure the final phases of that process worked out smoothly. I > thought there'd be a brief round, at least within the maintainers group > (and maybe this thread is it) where we reconcile the

Re: DRAFT 1.1 roadmap posted

On Thu, Nov 20, 2008 at 6:46 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > OK, so I'm going to add the "lots of +0" stuff to the draft, and the > note about ORM aggregation, that should have read "ORM identity map". OK, draft updated; hopefully it's a bit more sane now. Also, one

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

On Thu, Nov 20, 2008 at 9:47 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote: > ... >> # Using RequestContext >> def myview(request, *args): >># some code here... >>request.render('template_name.html', {...}) > ... >> >>

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

On Thu, Nov 20, 2008 at 10:23 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote: > > On Thu, Nov 20, 2008 at 9:47 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: >> >> On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote: >> ... >>> # Using RequestContext >>> def myview(request, *args): >>>

Features for 1.1? Tickets #8274, #3400

Are these slated to be in 1.1? #8274 would provide one of the more useful features by sites with many users. Where we could use email addresses as username. Would be nice just like you can set the pk in your model to be able to provide a field that is_username. #3400 I believe will provide