Re: Requesting Django to make authorization more flexible and secure for SAAS projects.

Oops. That was me who reported the discussion by accident (iPhone). Disregard. -- 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

Re: Deprecating cmemcache, adding pylibmc

I recently implemented a custom caching backend to add support for pylibmc on a large site due to issues with cmemcache. For the most part the 'pylibmc' APIs are the same as 'python-memcached' and 'cmemcache'. One changed behavior I ran into with 'pylibmc' that I did not experience with

Re: Fixing middleware/view decorator handling of content iterators

I didn't think about the author of a `HttpResponse` subclass needing to know all potential middleware that will not work with that particular response class. That is definitely a problem. However, I don't think that exposing a capabilities based API on `HttpResponse` is the answer. If we do that,

Re: Requesting Django to make authorization more flexible and secure for SAAS projects.

I suppose it was a bit of a question for django users. I apologize for not explaining that part of it. The reason I approached it that way wasn't to get a solution (although I would've gladly accepted one over wanting to change the base) is because I didn't know exactly what to request for my

Re: Deprecating cmemcache, adding pylibmc

On Sun, Feb 21, 2010 at 8:32 PM, Jacob Burch wrote: > This is in regards to Tickets #11675 and #12427. A bit more background: I've been told at PyCon that cmemcached is unmaintained and deliberately being left to die in favor of pylibmc. Because of that I'm +1 on your

Re: Fixing middleware/view decorator handling of content iterators

Hi, On Mon, Feb 22, 2010 at 12:39:40AM +, Luke Plant wrote: > On Sunday 21 February 2010 23:07:35 Forest Bond wrote: > > > Simply knowing whether or > > not the response is streaming and whether or not it has a known > > size is sufficient for knowing whether or not you should cache it. >

Deprecating cmemcache, adding pylibmc

This is in regards to Tickets #11675 and #12427. Review of the problems - There are two overarching problems with Django's current implementation of memcached as a backend: A) The import tree method of picking the appropriate library (if I have cmemcache use it, if not use python-memcache,

Re: Fixing middleware/view decorator handling of content iterators

On Sunday 21 February 2010 23:07:35 Forest Bond wrote: > Simply knowing whether or > not the response is streaming and whether or not it has a known > size is sufficient for knowing whether or not you should cache it. I can't find it now, but someone definitely had a use case where they

Re: Potential bug in select_related() as of Beta

On Mon, Feb 22, 2010 at 7:45 AM, subs...@gmail.com wrote: > Sorry to be pushy, but I would like to bump this or find the next tree > to bark up. A bug report is the best way forward here. When you make your report, obviously include the models, ORM query and SQL fragment that

Re: Requesting Django to make authorization more flexible and secure for SAAS projects.

On Mon, Feb 22, 2010 at 7:41 AM, orokusaki wrote: > I'm developing an SAAS which means that I will have Accounts and those > Accounts will have Users. Each account's Users are completely > orthogonal to the Users of another Account. When a user logs in, > they'll supply

Re: Moving all validation into the model layer.

On Mon, Feb 22, 2010 at 7:15 AM, orokusaki wrote: > Does anyone have interest in this? 1) Possibly. There are some complications to what you proposed. Model Validation has a lot of history, and things are they way they are for a reason -- and often, that reason is

Re: Potential bug in select_related() as of Beta

Sorry to be pushy, but I would like to bump this or find the next tree to bark up. -S On Feb 17, 9:42 pm, "subs...@gmail.com" wrote: > bmodels.Contact.objects.select_related('IR_contact','consumer_contact','pro­gram','consumer').filter(consumer__file=file).order_by('- >

Requesting Django to make authorization more flexible and secure for SAAS projects.

I'm developing an SAAS which means that I will have Accounts and those Accounts will have Users. Each account's Users are completely orthogonal to the Users of another Account. When a user logs in, they'll supply an Account ID, a username, and a password so username only needs to be unique with

Re: Moving all validation into the model layer.

Unless I misunderstand what you're looking for, the link Brett provided explains that this is a feature that is coming to Django. Some useful links: The original ticket: http://code.djangoproject.com/ticket/6845 The patch: http://code.djangoproject.com/changeset/12098 The branch:

Re: Moving all validation into the model layer.

Does anyone have interest in this? -- 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

Re: Fixing middleware/view decorator handling of content iterators

Hi, On Sun, Feb 21, 2010 at 10:44:07PM +0800, Russell Keith-Magee wrote: > To me, it seems like what we need to be able to capture in a response > object is the set of capabilities that a response supports -- For > example: > > * Can I determine the length of this response? > * Can I inspect

Re: Fixing middleware/view decorator handling of content iterators

Hi, On Sun, Feb 21, 2010 at 01:28:23AM -0800, Tai Lee wrote: > On Feb 21, 7:46 am, Forest Bond wrote: > > Okay, I think "disabled_middleware" is a bad name because it doesn't > > actually > > imply that all middleware should be disabled.  Anyway, it seems like > >

Re: Fixing middleware/view decorator handling of content iterators

On Sun, Feb 21, 2010 at 5:28 PM, Tai Lee wrote: > On Feb 21, 7:46 am, Forest Bond wrote: >> Okay, I think "disabled_middleware" is a bad name because it doesn't actually >> imply that all middleware should be disabled.  Anyway, it seems like

Re: Fixing middleware/view decorator handling of content iterators

On Sun, Feb 21, 2010 at 5:22 AM, Forest Bond wrote: > Hi, > > Sorry for the volume of messages, but I had one more note to add. ;) > > On Sat, Feb 20, 2010 at 03:46:52PM -0500, Forest Bond wrote: >> Here are the use cases that have been identified: >> >> 1. A content

Re: Fixing middleware/view decorator handling of content iterators

On Feb 21, 7:46 am, Forest Bond wrote: > Okay, I think "disabled_middleware" is a bad name because it doesn't actually > imply that all middleware should be disabled.  Anyway, it seems like > middleware > could just check if isinstance(response,