Re: Project-wide cache prefix (low-level API)
On Wed, Jun 16, 2010 at 1:04 AM, Giuseppe Ciotta wrote: > On Wed, Jun 16, 2010 at 12:46 AM, Jeremy Dunck wrote: >> On Sun, Jun 13, 2010 at 7:18 AM, lenz wrote: >>> Could you share your code with us? >>> Thanks you! >> >> This might help: >> http://gist.github.com/425403 > > I have some similar code here: http://gist.github.com/439868 > > It might be better because it wraps an arbitrary cache backend adding > prefix handling, it's not limited to memcache. Uhm, http://gist.github.com/425403 does indeed support an arbitrary backend, there's just a call to _get_memcache_timeout() which should be changed in order to make it completely backend agnostic. I left "*args, **kwargs" signatures everywhere to avoid dealing with parameters. -- 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: Project-wide cache prefix (low-level API)
On Wed, Jun 16, 2010 at 12:46 AM, Jeremy Dunck wrote: > On Sun, Jun 13, 2010 at 7:18 AM, lenz wrote: >> Could you share your code with us? >> Thanks you! > > This might help: > http://gist.github.com/425403 I have some similar code here: http://gist.github.com/439868 It might be better because it wraps an arbitrary cache backend adding prefix handling, it's not limited to memcache. It omits the prefix if the key name starts with the domain of the current Site. This is important for us because sometimes we want to share cache keys with other clients, and in this situation they shouldn't be aware of the particular prefix in use. It lacks coverage of new cache methods added in 1.2. -- 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: Process discussion: reboot
On Tue, Apr 20, 2010 at 4:39 PM, Jacob Kaplan-Moss wrote:
> On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta wrote:
>> Having an additional field{s} in the ticket, only accessible to core
>> developers, where they would put the "official" (as in: approved by a
>> core developer) triage status of the ticket, could improve the
>> efficency of the tickets review.
>
> I'm hearing a trend that folks are often confused over what's
> "official" versus "unofficial" in Trac.
>
> However, I'm wary of committer-only fields -- it adds an additional
> burden on us to keep 'em up-to-date, and I don't like the idea of
> preventing people who want to contribute from doing so.
My personal opinion is that the community should continue using the
fields we have now, because they ease the ticket evaluation job of
core developers.
I don't think adding additional fields will add burden for two reasons:
- this information is going to be easily shared between developers
- developer can have a better understanding of the whole situation,
because they can trust these field.
> So, what do you think of just adding some sort of different display to
> comments or to ticket changes made by members of the core team? You
> know how on blogs comments by the original author are highlighted?
> Something like that. I think it'd help people know when something
> "official" happened.
This would be super cool... really. But still, for reporting, "core
devs" fields look better to me. Having both fields and "featured
comments" would be perfect.
As I side note, I've switched from Trac to Redmine for my current
project, and it is *so* much easier to administer, there's *so* less
noise in tickets, and out of the box isn't a PITA as Trac is. I'm
extremely happy with it and I highly suggest to have a look at it
(it's ruby though, so we may be a little bit limited in terms of
hacking on it).
--
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: Process discussion: reboot
On Mon, Apr 19, 2010 at 4:19 PM, Jacob Kaplan-Moss wrote:
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
My understanding is that write access to triage stage and tickets
details is granted to everybody (even to anonymous users), and
everybody can change everything, thus making this data not 100%
reliable.
Having an additional field{s} in the ticket, only accessible to core
developers, where they would put the "official" (as in: approved by a
core developer) triage status of the ticket, could improve the
efficency of the tickets review.
--
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: logialogin_required does not check User.is_active
On Wed, Mar 17, 2010 at 8:54 AM, Russell Keith-Magee wrote: > > In the interim, there are two other ways you could limit your exposure > to this problem (other than the obvious "write your own > login_required" check): > > * Use a permissions check in addition to the login_required check -- > as noted it the docs, has_perm() will check the is_active status. > > * Use a short-lived session (say, 24 hours). If a user has to log in > every 24 hours, the is_active check will be re-evaluated every 24 > hours. Also, a middleware which checks for user.is_active and calls logout(request) looks fine in the short term, look at http://www.djangosnippets.org/snippets/1105/ -- 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: Feedback on ticket #12399
On Wed, Jan 27, 2010 at 1:19 AM, Russell Keith-Magee wrote: > On Wed, Jan 27, 2010 at 12:30 AM, Giuseppe Ciotta wrote: >> http://code.djangoproject.com/ticket/12399 >> >> It's a nasty bug which leads to a 100% cache misses situation on >> memcached when using long keys timeouts. >> >> Do you think we can have this included in 1.2? Should i mark it with >> Version:1.2 or something? The patch itself is trivial. > > Marking the ticket as "Milestone 1.2" will put it on the list of bugs > that will be considered for 1.2. > > Looking at the patch, the one thing that is missing is tests. Without > tests, a patch won't get anywhere near trunk, no matter how trivial. The test is included in the latest patch and bug's marked for the 1.2 milestone. The patch may introduce a slightly backward-incompatible change for people using long timeouts as absolute timestamps, but in my opinion this is highly unlikely and the documentation never mentioned anything about it. -- 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.
Feedback on ticket #12399
http://code.djangoproject.com/ticket/12399 It's a nasty bug which leads to a 100% cache misses situation on memcached when using long keys timeouts. Do you think we can have this included in 1.2? Should i mark it with Version:1.2 or something? The patch itself is trivial. -- 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.
