Re: Django NoSQL support status?

I've been away from these efforts for a while, but someone interested in bridging SQL/NoSQL in Django might find these links interesting: http://msdn.microsoft.com/library/bb308959.aspx http://cacm.acm.org/magazines/2011/4/106584-a-co-relational-model-of-data-for-large-shared-data-banks/fulltext

Re: Purpose of constant_time_compare?

This is quickly becoming off topic, but I'll bite ;D. On Wed, Dec 8, 2010 at 10:52 PM, Gabriel Hurley wrote: > You wanna hand over your paycheck now, or later? :-) > > I know someone with a functional white-hat timing attack script sitting on > their laptop. They've been

Re: Purpose of constant_time_compare?

Yea... in reality I'd bet my paycheck that the answer is no. Despite Coda's blog post, you can't use the jitter in HTTP requests to gain any insight into where a string match fails. Even if you could do so with hundreds of requests, it's fairly obvious that an attack is taking place when you get

Re: Application to update the Test Suite

On Fri, Apr 9, 2010 at 5:29 PM, Gabriel Hurley wrote: > Maybe it's an overly simplistic question, but: what makes the tests > slow currently? It's not simply the volume of them. It's more than > possible for Python to race through hundreds of tests per second under > the right

Re: Deprecating cmemcache, adding pylibmc

> At this point in the release process, I'm not sure we can do > everything that's being talked about in this thread. Given that we're > feature-frozen and that there's no way we can spring a completely new > cache backend on people at the last minute, here's what's possible > within our release

Re: What do people think about the get_absolute_url proposal?

On Wed, Dec 16, 2009 at 11:10 AM, Alex Gaynor <alex.gay...@gmail.com> wrote: > On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone <mjmal...@gmail.com> wrote: >>> The way i see it (which may be wrong), this is not a proposal to make >>> the request object global or repl

Re: What do people think about the get_absolute_url proposal?

> The way i see it (which may be wrong), this is not a proposal to make > the request object global or replace/refactor the contrib.site app. In > fact, some of the use cases mentioned strike me as things that would > require overriding the default get_absolute_url method anyway. It > seems to me

Re: What do people think about the get_absolute_url proposal?

On Sat, Dec 12, 2009 at 3:58 PM, Ivan Sagalaev <man...@softwaremaniacs.org> wrote: > Mike Malone wrote: >> On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee >> <freakboy3...@gmail.com> wrote: >>>  4. I share Mike's concern about using settings.SITE_ID to det

Re: What do people think about the get_absolute_url proposal?

On Tue, Dec 8, 2009 at 7:52 PM, Russell Keith-Magee wrote: >  4. I share Mike's concern about using settings.SITE_ID to determine > the current host, but I'm not sure I have any suggestions on how we > could practically use request, short of encouraging the use of a >

Re: What do people think about the get_absolute_url proposal?

I'd much rather have this information come from the current request vs. coming from settings. Relying on the Site is particularly annoying. I like the implementation of build_absolute_uri() in django.http.HttpRequest. The hard part is getting the request object to a place where it's usable by

Re: Template Caching - Ticket #6262

K, I just uploaded another patch to ticket #6262. Comments inline. On Mon, Nov 16, 2009 at 5:58 AM, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Thu, Nov 12, 2009 at 9:15 AM, Mike Malone <mjmal...@gmail.com> wrote: >> Sup, >> >> I've been working

Template Caching - Ticket #6262

Sup, I've been working on template caching (ticket #6262) with a mister Alex Gaynor. The patch is getting pretty stable and I think it's close to merge-able, so if anyone wants to take a look at what we've got and provide feedback: go! Interesting background reading for people who haven't been

Re: Integrating Django with Tornado's web server

> I just checked in change to Tornado that enables you to run any WSGI- > compatible framework on Tornado's HTTP server so that Django apps > could run on top of Tornado's HTTP server and benefit from some of the > performance work we have done. (I just sent a message to django-users@ > with

Re: Template Caching

> On Thu, Aug 6, 2009 at 2:55 AM, Russell > Keith-Magee wrote: >> As is noted in the ticket, one of the reasons that this wasn't done >> originally was that the performance boost wasn't seen as being that >> considerable. > > I suspect there'll be a goodly speedup even for

Template Caching

Hey everyone, I've been working on a patch for Django that would allow you to optionally cache templates after they've been lexed and parsed (compiled) by the template engine. I've got things far enough along that I have a working implementation, so I thought I'd share here and see if anyone had

Re: Proposal: user-friendly API for multi-database support

> On Sep 10, 10:24 pm, "Mike Malone" <[EMAIL PROTECTED]> wrote: > > At Pownce, for example, we stick users to the master database for some > > period of time (a couple of seconds, usually) after they post a new note. > > The problem here (as Malcolm poin

Re: Proposal: user-friendly API for multi-database support

> Well... To be sure save() should always go to master because on slaves > you just don't have permissions to save anything. So a parameter to > save() is redundant. > Not so. There are certainly use-cases for more sophisticated database architectures where, for example, the majority of the

Re: Proposal: user-friendly API for multi-database support

Wow... like Malcom said, lots to digest here. So to start, the "simple" master-slave replication scenario turns out not to be so simple once you get into the implementation details. Replication lag being what it is, you almost never way to query the slave for every SELECT. At Pownce, for

Re: Call for testing: streaming uploads (#2070)

Hey Jacob, FYI: Our environment isn't that bizarre (Apache/Debian), but we've been running patch #2070 in production on Pownce for a couple weeks now (we actually ran a back-ported version of #2070 on 0.96 before we moved to trunk). It's been working beautifully, and has really improved