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
h
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 honing the statistical a
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 t
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 conditions.
Tests a
> 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 pr
On Wed, Dec 16, 2009 at 11:10 AM, Alex Gaynor wrote:
> On Wed, Dec 16, 2009 at 2:02 PM, Mike Malone wrote:
>>> 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
>>&g
> 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 l
On Sat, Dec 12, 2009 at 3:58 PM, Ivan Sagalaev
wrote:
> Mike Malone wrote:
>> 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
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
> template tag like {% obj_url
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 model
K, I just uploaded another patch to ticket #6262. Comments inline.
On Mon, Nov 16, 2009 at 5:58 AM, Russell Keith-Magee
wrote:
> On Thu, Nov 12, 2009 at 9:15 AM, Mike Malone wrote:
>> Sup,
>>
>> I've been working on template caching (ticket #6262) with a mister
&g
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 pa
> 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 getti
> Do you also intend to contribute some code? You could team up with
> Mitch on the SimpleDB backend, for example (at least, you seemed to be
> most interested in that).
Sure.
> Some higher-level features like JOINs can be useful *and* practical
> even on non-SQL DBs. Of course, emulated operati
Hey hey,
If we're gunna start talking about a more generic DB API then count me in!
For what it's worth, I really think that a basic API that only
supports a few simple operations (get, set, and delete, primarily) is
the way to go. There's not enough commonality between datastores at a
higher le
> 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 the common case, since
>
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
> 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 pointed ou
> 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 databa
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 example,
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 performanc
21 matches
Mail list logo
