Re: Admin - Selector Inlines in 1.3?
That would be a rather nice feature. +1 On Thu, Jul 15, 2010 at 2:21 AM, andybak wrote: > Hi, > > As far as I know this is the only major chunk of Zain's SOC work that > didn't make it into 1.2 > > There's a ticket for it: http://code.djangoproject.com/ticket/12509 > that's at 'design decision needed' > > What would be needed to get this rather nice feature into 1.3? > > cheers, > > Andy > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Invalid SQL generated by objects.all()[:1]?
On Thu, 2010-07-15 at 15:57 -0600, Ian Kelly wrote: > > > > It may be that they aren't allowed by the spec, but the only database > > (that Django includes an adapter for) that doesn't support them > > (AFAIK) is MySQL. Further, Event.objects.all()[:1] doesn't generate a > > subquery at all. > > Er, I'm pretty sure that MySQL does support both ORDER BY and > LIMIT/OFFSET. At least, it is documented as supporting them. > > The supported database that does have a problem with LIMIT/OFFSET is > Oracle. The backend contains a workaround, which is implemented by a > custom SQLCompiler in django.db.backends.oracle.compiler, and it > involves wrapping the original query in a subquery. > The MonetDB > backend may be doing something similar, which would explain why that > query is generating a subquery. That seems like an explanation for why they mentioned subqueries, though MonetDB supports LIMIT OFFSET according to their docs. > All of the internally supported databases support ORDER BY, so I can't > offer any hints there. PostgreSQL supports ORDER BY/LIMIT in subqueries, which I believe is an extension to the SQL standard. SQL Standard formulation for this query syntax is new in SQL:2008 where it is now called OFFSET ... FETCH ... To my knowledge only DB2 and Postgres support the new standard syntax. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Accessible Command Output using self.stdout & self.stderr
Hi guys, To support http://code.djangoproject.com/ticket/13476 , it'd be great if someone converted current prints to use self.stdout and self.stderr. Alternative suggestions are welcome... On Fri, Jul 16, 2010 at 6:38 AM, Russell Keith-Magee wrote: > On Fri, Jul 16, 2010 at 5:39 AM, Gregor Müllegger > wrote: >> Related to the issue with stdout/stderr: >> >> I'm aware that Russ is not a big fan of Monkeypatching :) > > True :-) > >> but I think this >> would be a legal case - since there is no other way of intercepting the real >> stdout output (I'm not sure but this might be even documented in python docs, >> that its ok to overwrite sys.stdout and sys.stderr with your own objects). > > If you want to get really technical, there *is* another way it can be > done -- at least, if you're on a *NIX; you can redirect the file > descriptors that represent stdout/stderr. It's low-level plumbing, but > it works. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
memcached-based-cache - timeout=0 does not work as intended by memcached
Hello, I am not quite sure if this is the right mailinglist but as long as my remarks are about a core-component of django I hopefully chose the right list. Dealing with cache-stuff in Django I realized that it seems to be impossible to use a timeout=0 (which in terms of memcached meant that the item would never expire unless it has to make way for new items due to memory shortage). This is because even still in the most current trunk-version the timeout is calculated (in django.core.backends.memcached.CacheClass._get_memcache_timeout) as timeout = timeout or self.default_timeout where timeout is one of the parameters given to _get_memcache_timeout. So as long as timeout=0 always the default_timeout will be used. Maybe this behaviour is intended to prevent memcached being filled up with items that never expire. In my opinion it may be better to enable developers to use the timeout-values as intended by memcached (where 0 means no expiration at all). So I would like to suggest to change the default value in all method signatures of the memcached.CacheClass (and whereever it whould be necessary) from 0 to None and to replace the line above by an if-clause as if timeout is None: timeout = self.default_timeout This is not as elegant as the original version but now it would be possible to use 0 as a timeout. If it would help I can try to open a ticket and provide a first path against the current trunk. With best regards Carsten Reimer -- Carsten Reimer Web Developer carsten.rei...@galileo-press.de Phone +49.228.42150.73 Galileo Press GmbH Rheinwerkallee 4 - 53227 Bonn - Germany Phone +49.228.42150.0 (Zentrale) .77 (Fax) http://www.galileo-press.de/ Managing Directors: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker HRB 8363 Amtsgericht Bonn -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
High Performance solutions are needed to do things like urlretrieve
urlretrieve works fine. However, when file size get very large. It goes on forever, and even fails. For instance, one of download .zip file is of 363,096KB. Particularly, when trying to get, with urlretrieve, a zipped folder of a very large size, it could take up to 20 to 30 minutes. Often it fails, never any problem with smaller folders. Any solution for this? Regards. David -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: memcached-based-cache - timeout=0 does not work as intended by memcached
+1 Sent from my mobile device. On Jul 16, 2010 6:54 AM, "Carsten Reimer" wrote: Hello, I am not quite sure if this is the right mailinglist but as long as my remarks are about a core-component of django I hopefully chose the right list. Dealing with cache-stuff in Django I realized that it seems to be impossible to use a timeout=0 (which in terms of memcached meant that the item would never expire unless it has to make way for new items due to memory shortage). This is because even still in the most current trunk-version the timeout is calculated (in django.core.backends.memcached.CacheClass._get_memcache_timeout) as timeout = timeout or self.default_timeout where timeout is one of the parameters given to _get_memcache_timeout. So as long as timeout=0 always the default_timeout will be used. Maybe this behaviour is intended to prevent memcached being filled up with items that never expire. In my opinion it may be better to enable developers to use the timeout-values as intended by memcached (where 0 means no expiration at all). So I would like to suggest to change the default value in all method signatures of the memcached.CacheClass (and whereever it whould be necessary) from 0 to None and to replace the line above by an if-clause as if timeout is None: timeout = self.default_timeout This is not as elegant as the original version but now it would be possible to use 0 as a timeout. If it would help I can try to open a ticket and provide a first path against the current trunk. With best regards Carsten Reimer -- Carsten Reimer Web Developer carsten.rei...@galileo-press.de Phone +49.228.42150.73 Galileo Press GmbH Rheinwerkallee 4 - 53227 Bonn - Germany Phone +49.228.42150.0 (Zentrale) .77 (Fax) http://www.galileo-press.de/ Managing Directors: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker HRB 8363 Amtsgericht Bonn -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Patch: Indefinite args for simpletags and inclusion tags
Hi, I've patched django to allow indefinite args for simple tags and inclusion tags. My impetus for doing so was as follows: I have a project that registers inclusion template tags for methods on objects in a registry. (http://github.com/melinath/pipettes/blob/ master/templatetags/pipettes.py) In order to correctly set the tag's name (and provide other basic functionality in the future) I have to wrap the method. However, I have no way of knowing how many arguments the method will have, and I don't want to restrict people who might register objects to a certain number of arguments. So the wrapper should accept *args. Unfortunately, django seems to purposely ignore the possibility of *args in creating simple tags and inclusion tags, instead checking only how many args and default args have been specified for the node's function. Before posting the patch to django's ticketing system, I wanted to check whether this would be a non-trivial patch and whether there might be any good alternatives. Thanks! --Stephen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Patch: Indefinite args for simpletags and inclusion tags
On Fri, Jul 16, 2010 at 1:07 PM, Stephen Burrows < stephen.r.burr...@gmail.com> wrote: > Before posting the patch to django's ticketing system, I wanted to > check whether this would be a non-trivial patch and whether there > might be any good alternatives. > Hard to tell without seeing the patch. :-) Could you stick it somewhere we can see it? Personally I like to see them in Trac, since it comes with pretty colors. If there isn't a ticket already out there for this I see no problem with creating one. We can always close it if it gets rejected. Cheers Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
request.is_ajax() and hidden iframe kludge => request.is_framejax()?
People doing ajax have probably hit the "XMLHttpRequest doesn't do file
uploads (at least not non-browser-specifically), use a hidden iframe
kludge or flash" issue. Anyway, maybe that will change one day, but
right now:
Things that try to handle file uploads via hidden iframes, like the
jquery-form plugin, where certain kinds of server responses need to be
wrapped/escaped to avoid snafu [1], make it desirable to be able to
distinguish on the server side between non-ajax, "true" ajax, and
javascript-driven hidden-iframe type requests.
The hidden-iframe requests will AFAIK show up with request.is_ajax() ==
False to django. So a "done thing" (I think) to distinguish between the
non-ajax and hidden-iframe requests seems to be to just have an extra
field to act as a pseudo-header, i.e.
or "?X-Requested-With=ScriptedIFrame"
Obviously people might pick all sorts of names and values for such a
hidden field, but there's some precedent in the wild for using the name
"X-Requested-With" in particular for the pseudo-header by analogy with
the real header: see e.g.
http://click.apache.org/docs/click-api/org/apache/click/Context.html#isAjaxRequest%28%29
OTOH I pulled "ScriptedIFrame" for the value from nowhere, but IMO using
"XMLHttpRequest" for the value would be very poor form.
In any case, Django's request.is_ajax() currently only checks for the
real header, and probably rightly so (browser policy assumptions).
It might nonetheless be nice for django to have some support for
checking for some particular pseudo-header. Or maybe it's too dumb
(it's friday...) or too niche to bother with:
* A. Do nothing. It's not exactly hard for users who know they need it
to just write their own function to do such a check. There's just risk
of proliferation of pseudo-headers with different names and values that
all effectively mean the same thing, and in a django context - reusable
apps - that could get tiresome.
* B. Add a request.is_framejax() (or whatever name) to help check for a
pseudo header, leaving request.is_ajax() as-is, say something like
class HttpRequest(object):
...
def is_framejax(self):
return (self.POST.get('X-Requested-With') == 'ScriptedIFrame')
or (self.GET.get('X-Requested-With') == 'ScriptedIFrame')
...
* C. Adjust request.is_ajax() check for the pseudo-header as well as
the real header, and then have a request.is_framejax() (or whatever) to
distinguish between true ajax and the hidden-iframe cases.
But I think C. might be bad for security (e.g. the CSRF framework) and
backward-compat though, so I guess A. or B. are probably best.
[1] http://jquery.malsup.com/form/#file-upload
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Patch: Indefinite args for simpletags and inclusion tags
I went ahead and made a ticket with the patch. Thanks! http://code.djangoproject.com/ticket/13956 --Stephen On Jul 16, 1:25 pm, Tobias McNulty wrote: > On Fri, Jul 16, 2010 at 1:07 PM, Stephen Burrows < > > stephen.r.burr...@gmail.com> wrote: > > Before posting the patch to django's ticketing system, I wanted to > > check whether this would be a non-trivial patch and whether there > > might be any good alternatives. > > Hard to tell without seeing the patch. :-) > > Could you stick it somewhere we can see it? Personally I like to see them > in Trac, since it comes with pretty colors. If there isn't a ticket already > out there for this I see no problem with creating one. We can always close > it if it gets rejected. > > Cheers > Tobias > -- > Tobias McNulty > Caktus Consulting Group, LLC > P.O. Box 1454 > Carrboro, NC 27510 > USA: +1 (919) 951-0052http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
djangoproject.com hiccup: community section configured wrong
Did someone fiddle with the server recently? Scott Turnbull join pointed out a problem on http://www.djangoproject.com/community/ -- some links point to example.com. I looked just now, and it looks like the importer ran incorrectly for one run -- from "My thoughts on DjangoCon Berlin 2010" to "First Post" on the run at July 9, 2010 at 4:04 PM. Any ideas? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: High Performance solutions are needed to do things like urlretrieve
On Jul 16, 1:51 pm, shi shaozhong wrote: > Any solution for this? Yes; plz post usage questions to django-users. Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: djangoproject.com hiccup: community section configured wrong
On Fri, Jul 16, 2010 at 4:20 PM, Jeremy Dunck wrote: > Did someone fiddle with the server recently? > > Scott Turnbull join pointed out a problem on > http://www.djangoproject.com/community/ -- some links point to > example.com. > > I looked just now, and it looks like the importer ran incorrectly for > one run -- from "My thoughts on DjangoCon Berlin 2010" to "First Post" > on the run at July 9, 2010 at 4:04 PM. > > Any ideas? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > Are we sure it wasn't a problem with whoevers blog that is? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: request.is_ajax() and hidden iframe kludge => request.is_framejax()?
Hi, On Jul 16, 7:25 pm, David De La Harpe Golden wrote: > People doing ajax have probably hit the "XMLHttpRequest doesn't do file > uploads (at least not non-browser-specifically), use a hidden iframe > kludge or flash" issue. Anyway, maybe that will change one day It's already changing, modern browsers can do what you want (google for html5 file uploads). I don't see any reason to support something like you suggest; we should support standards and not workarounds (just my opinion). Imo the best way currently is to use the new apis and fallback to flash or whatever if needed (I actually guess flash is the best fallback here). > The hidden-iframe requests will AFAIK show up with request.is_ajax() == > False to django. So a "done thing" (I think) to distinguish between the > non-ajax and hidden-iframe requests seems to be to just have an extra > field to act as a pseudo-header, i.e. > > This input field is easily fakeable. An attacker can't fake your browsers XHR requests, which makes request.is_ajax somewhat secure and trustable. I don't see how your solution could achieve that. > or "?X-Requested-With=ScriptedIFrame" Same as above. > It might nonetheless be nice for django to have some support for > checking for some particular pseudo-header. -1, mostly due to the fact that it's something most people won't need and you can easily inject that info using a middleware yourself. Hence I am for solution A. Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: djangoproject.com hiccup: community section configured wrong
On Jul 16, 11:20 pm, Jeremy Dunck wrote: > I looked just now, and it looks like the importer ran incorrectly for > one run -- from "My thoughts on DjangoCon Berlin 2010" to "First Post" > on the run at July 9, 2010 at 4:04 PM. Aren't those all from http://nomadblue.com/? Maybe Hector Garcia's feed was broken (eg contrib.sites was still set to example.com). Cheers, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: djangoproject.com hiccup: community section configured wrong
On Fri, Jul 16, 2010 at 4:29 PM, Alex Gaynor wrote: ... > Are we sure it wasn't a problem with whoevers blog that is? D'oh. You're right, I thought since it affected multiple entries, it must be multiple sites, all those entries are from the same site. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Fwd: djangoproject.com hiccup: community section configured wrong
-- Forwarded message -- From: Jeremy Dunck Date: Fri, Jul 16, 2010 at 4:33 PM Subject: Re: djangoproject.com hiccup: community section configured wrong To: django-developers@googlegroups.com On Fri, Jul 16, 2010 at 4:29 PM, Alex Gaynor wrote: ... > Are we sure it wasn't a problem with whoevers blog that is? D'oh. You're right, I thought since it affected multiple entries, it must be multiple sites, all those entries are from the same site. His site is fixed now. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: djangoproject.com hiccup: community section configured wrong
On Fri, Jul 16, 2010 at 6:33 PM, Jeremy Dunck wrote: > On Fri, Jul 16, 2010 at 4:29 PM, Alex Gaynor wrote: > ... >> Are we sure it wasn't a problem with whoevers blog that is? > > D'oh. You're right, I thought since it affected multiple entries, it > must be multiple sites, all those entries are from the same site. See ticket [1]13923. Regards, -- Ramiro Morales | http://rmorales.net 1. http://code.djangoproject.com/ticket/13923 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: request.is_ajax() and hidden iframe kludge => request.is_framejax()?
> This input field is easily fakeable. An attacker can't fake your > browsers XHR requests, which makes request.is_ajax somewhat secure and > trustable. I don't see how your solution could achieve that. is_ajax() simply checks an HTTP header. It is easily set by an attacker. On Jul 16, 2:30 pm, Florian Apolloner wrote: > Hi, > > On Jul 16, 7:25 pm, David De La Harpe Golden > > wrote: > > People doing ajax have probably hit the "XMLHttpRequest doesn't do file > > uploads (at least not non-browser-specifically), use a hidden iframe > > kludge or flash" issue. Anyway, maybe that will change one day > > It's already changing, modern browsers can do what you want (google > for html5 file uploads). I don't see any reason to support something > like you suggest; we should support standards and not workarounds > (just my opinion). Imo the best way currently is to use the new apis > and fallback to flash or whatever if needed (I actually guess flash is > the best fallback here). > > > The hidden-iframe requests will AFAIK show up with request.is_ajax() == > > False to django. So a "done thing" (I think) to distinguish between the > > non-ajax and hidden-iframe requests seems to be to just have an extra > > field to act as a pseudo-header, i.e. > > > > > This input field is easily fakeable. An attacker can't fake your > browsers XHR requests, which makes request.is_ajax somewhat secure and > trustable. I don't see how your solution could achieve that. > > > or "?X-Requested-With=ScriptedIFrame" > > Same as above. > > > It might nonetheless be nice for django to have some support for > > checking for some particular pseudo-header. > > -1, mostly due to the fact that it's something most people won't need > and you can easily inject that info using a middleware yourself. Hence > I am for solution A. > > Cheers, > Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
[GSOC] Query Refactor Update
Hey all, The last while has been spent continuing the fight to make aggregates work correctly, Russ provided some good insight that's gotten me farther on it. All that code is in my query-refactor-aggregates branch on github, as it's not fully working ATM. This week I also pushed a few updates to SVN, including support for F() expressions in updates, and another small fix for bulk updates. My goals for next week are to continue the aggregates work (maybe even finish it!), as well as to clean up the errors for trying to use impossible features, right now they're a bunch of asserts, but ideally they should be clean, expressive error messages as. I'm also going to work on getting a ListField implemented, in principle the storage/retreival of one shouldn't' be too bad, however MongoDB also supports querying on them (as one might across a foreign key relationship in a relational database), and I imagine some refactoring will be necessary there. Since this is about the halfway point of GSOC I'll give a general overview: we have a working MongoDB backend, with many implemented features, and a set of changes to Django itself (that don't break anything else of course) that enable this. Diligent readers will recall that originally a backend was the goal for the 2nd half of GSOC, with the first half being allocated to internal refactors. Seeing as how the backend is nearing completion the 2nd half will be targeted at these refactors, starting wiht the aggregation stuff I've been working on. Thoughts, questions, flames, nobel prizes nominations welcome, Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: memcached-based-cache - timeout=0 does not work as intended by memcached
+1 2010/7/16 Tobias McNulty : > +1 > > Sent from my mobile device. > > On Jul 16, 2010 6:54 AM, "Carsten Reimer" > wrote: > > Hello, > > I am not quite sure if this is the right mailinglist but as long as my > remarks are about a core-component of django I hopefully chose the right > list. > > Dealing with cache-stuff in Django I realized that it seems to be impossible > to use a timeout=0 (which in terms of memcached meant that the item would > never expire unless it has to make way for new items due to memory > shortage). This is because even still in the most current trunk-version the > timeout is calculated (in > django.core.backends.memcached.CacheClass._get_memcache_timeout) as > > timeout = timeout or self.default_timeout > > where timeout is one of the parameters given to _get_memcache_timeout. > > So as long as timeout=0 always the default_timeout will be used. > Maybe this behaviour is intended to prevent memcached being filled up with > items that never expire. > In my opinion it may be better to enable developers to use the > timeout-values as intended by memcached (where 0 means no expiration at > all). > > So I would like to suggest to change the default value in all method > signatures of the memcached.CacheClass (and whereever it whould be > necessary) from 0 to None and to replace the line above by an if-clause as > > if timeout is None: > timeout = self.default_timeout > > This is not as elegant as the original version but now it would be possible > to use 0 as a timeout. > > If it would help I can try to open a ticket and provide a first path against > the current trunk. > > > With best regards > > Carsten Reimer > > > > -- > Carsten Reimer > Web Developer > carsten.rei...@galileo-press.de > Phone +49.228.42150.73 > > Galileo Press GmbH > Rheinwerkallee 4 - 53227 Bonn - Germany > Phone +49.228.42150.0 (Zentrale) .77 (Fax) > http://www.galileo-press.de/ > > Managing Directors: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker > HRB 8363 Amtsgericht Bonn > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- Sergej Dergatsjev E-mail: sergej.dergats...@gmail.com Skype: SergejDergatsjev Site: http://www.eecho.info -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
