Re: ANN: Server upgrade on djangoproject.com

On Fri, Jan 28, 2011 at 3:33 PM, Jacob Kaplan-Moss wrote: > I'm starting the switchover to the new djangoproject.com server right > now. Might be around 5 mins of downtime or so. Migration should be complete now. I'm still cleaning up a few last-minute things, but if you

ANN: Server upgrade on djangoproject.com

Hi folks -- I'm starting the switchover to the new djangoproject.com server right now. Might be around 5 mins of downtime or so. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: #15183: wont fix follow up

Actually, not that I think about this again, the rationale behind my original proposal was this: since nulls are included in the output anyway we may as well count them. This way there are no surprises about what's counted and what's not. And users who do not want to count nulls should apply query

Re: #15183: wont fix follow up

Thanks for you input Russ. Yes, Count("*") does look cleaner but (based on a quick glance on the code) may require some serious rewiring. I'll give some more thought as to how this may be accomplished. Should I create a new ticket then or reopening the one I already put is fine? Cheers Sergiy On

Re: #15183: wont fix follow up

On Fri, Jan 28, 2011 at 11:05 PM, Sergiy Kuzmenko wrote: > A couple of points regarding this: > http://code.djangoproject.com/ticket/15183#comment:1. > > If nulls should not be counted then then they should be excluded from > results but they are not. > > You always get an

Re: Admin DateTimeShortcuts performance (feature request / improvement suggestion)

Thanks for the super fast reply, Russ! the way you put it makes sense to me, so I guess I'm going to start over with replacing just the DateTimeShortcuts script and trying to use that from within the inlines script. Regards, Fabian 2011/1/28 Russell Keith-Magee > On

Re: Admin DateTimeShortcuts performance (feature request / improvement suggestion)

On Fri, Jan 28, 2011 at 10:18 PM, Fabian Büchler wrote: > Hello Django developers, > > as this is my first post here, let me shortly introduce myself: > I'm Fabian Büchler, webdeveloper from Vienna, Austria; relatively new to > Django and just thinking about hacking on

#15183: wont fix follow up

A couple of points regarding this: http://code.djangoproject.com/ticket/15183#comment:1. If nulls should not be counted then then they should be excluded from results but they are not. You always get an entry for nulls (if they are present) with zero count which if you need them is a problem and

Admin DateTimeShortcuts performance (feature request / improvement suggestion)

Hello Django developers, as this is my first post here, let me shortly introduce myself: I'm Fabian Büchler, webdeveloper from Vienna, Austria; relatively new to Django and just thinking about hacking on Django itsself ... I've read all your contribution guidelines and I believe this to be the

Re: One Django instance, hundreds of websites

Graham is correct. I pointed out this in my reply to reviewboard method which works just like Jjdelc proposed, and that is incorrect way. So simply put: Changing settings object in middelwares is WRONG. If one changes the settings object before or after request, it will be in intermediate state

Re: One Django instance, hundreds of websites

On Friday, January 28, 2011 6:59:43 PM UTC+11, James Hancock wrote: > > I have one question about changing the site ID per request. > I assume that settings is imported from conf, and so in the end it is > simply changing the same SITE_ID to fit the current request Django is > handling. > >

Re: One Django instance, hundreds of websites

I have one question about changing the site ID per request. I assume that settings is imported from conf, and so in the end it is simply changing the same SITE_ID to fit the current request Django is handling. Does this ever become a problem? I am setting up around 250 sites for example. If the