Re: TemplateResponse and decorator_from_middleware

> These features have the stated purpose of allowing a response to be > altered by middleware or decorators. However, if a decorator causes the > template to be rendered, then such alterations will not happen. > > This is a serious issue, because decorators like these are often applied > on an

Re: TemplateResponse and decorator_from_middleware

Hi Luke, I actually faced a problem similar to this when I ported CBV from 1.3 to 1.2, and then tried to use the TemplateResponse with a couple of middleware decorators that I created from some custom middleware classes. If I recall properly, I was also having backwards incompatibility problems

Re: NoSQL support

> Please don't get me wrong. I have worked with RDBMS for more than a > decade but I alse use django-nonrel with MongoDB on a daily basis. I > also think that the approach django-mongokit takes is much more > natural for NoSQL data than just reusing the ORM. The ORM has no way > to express complex

Re: NoSQL support

> Did you guys consider providing a Document class that is entirely > separate from models.Model? > > Technically speaking teaching the ORM non-relational tricks is of > course possible but in reality the philosophy is entirely different > and you need to plan for NoSQL from the very beginning.

Re: model fields options

> Sounds like a bad idea to me. unique_together doesn't exist on a specific > field precisely because it isn't an option for any specific fields, it's for > a set of fields. All the other options belond to specific fields. > > Alex You're probably right about this, but (while we are on the

Re: URLfield with verify_exists hangs if given an unresponsive URL (#9857)

Hi Fabian, Are there tests that isolate this functionality? If there are, I can run them against 2.5 and 2.6 to give you some independent verification. If not, you should look into how to run the Django test suite, and write some targeted tests. Regards Eduardo On May 5, 3:07 am, Fabiant7t

Re: EmailField max_length of 75 characters should be 256 acccording to RFC 5321

> There are plenty of other workarounds -- the easiest is to note the > email field is optional and just create a RealUserEmail object with a > OneToOne to User. Given that, a hacky workaround in Django itself just > isn't going to happen. The right thing to do is to get the auth > refactor done

Re: ModelForm validation - a better way?

> For reference, here's where we'd be in that case (I still prefer the > context manager over the idea of two separate calls to something named > "validate"): > > def my_view(request): >     form = MyModelForm(request.POST or None) >     try: >         with form.validate(tweak=True) as obj: >    

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

here, including the core developers. I also have to say that you have made yourself available in a very generous manner of late; for that I am quite appreciative. Regards, Ed Gutierrez On Apr 28, 8:34 pm, Carl Meyer <c...@oddbird.net> wrote: > Hi Eduardo, > > On 04/28/2011 06:3

Re: Suggestion for improvement to template block/extends tags

Hi amagee- Have you tried this? base_a.html first {% block content %}{% block subcontent %}{% endblock %}{% endblock%} last base_b.html {% extends "base_a.html %} {% block content %}left{% block subcontent %}{% endblock %}right{% endblock %} template.html {% extends (either "base.a.html" or

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

4/28/2011 12:35 PM, legutierr wrote: > > > I just added a new patch in response to Carl's comments on the ticket. > > >http://code.djangoproject.com/ticket/13091 > > So, in the process of reviewing and tweaking this patch for commit, I > checked in the #django-dev IR

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

:28 pm, Carl Meyer <c...@oddbird.net> wrote: > Hi Eduardo, > > On 04/28/2011 12:35 PM, legutierr wrote: > > > I just added a new patch in response to Carl's comments on the ticket. > > >http://code.djangoproject.com/ticket/13091 > > So, in the process of revie

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

I just added a new patch in response to Carl's comments on the ticket. http://code.djangoproject.com/ticket/13091 Regards, Eduardo -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

I didn't link to where I uploded the patch. It is here: http://code.djangoproject.com/ticket/13091 On Apr 28, 1:43 am, legutierr <leguti...@gmail.com> wrote: > OK, I just uploaded a patch against trunk that should be consistent > with this discussion.  As I note in the ticket, I ke

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

t;c...@oddbird.net> wrote: > On 04/27/2011 02:02 PM, legutierr wrote: > > > Ok, I'll create a patch soon (with tests + documentation) that > > hopefully works for you.  I don't think it will be very complicated > > implementation-wise, just a few additional lines, I think.  With &g

Re: NoSQL support

+ 100 on this (oh, wait, do I not get that many votes? +10 then). Waldemar and Thomas (and the rest of the people contributing to django- nonrel) have worked very hard to advance Django and expand its use into new spheres. It would be great to see their work recognized by the core team, and to

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Carl- > Hmm, that's interesting. I'm not super-enthused about the complexity > there (Zen of Python: "if the implementation is hard to explain, it's a > bad idea"), but I think you're right that it's feasible. Note that > nullable fields would be ok to go ahead with (because NULL is not equal

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Carl- > With your proposed change, if I happen to have a FavoriteBirthdayPresent > in the database for a given year with an empty "username" field, it > would incorrectly prevent any user from creating their own > FavoriteBirthdayPresent for that year. > > I'll readily admit that's a corner

"unique_together" only validated in modelform.is_valid() if ALL of the referenced fields are included in the form (Ticket #13091)

The subject didn't make any sense. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to

"unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Thanks for your response, Florian. > > modelform.is_valid() fails to anticipate database integrity errors > > when those errors involve any fields that are not part of that form > > itself. > > That is wanted behaviour, eg consider my workflow: > > class SomeForm(ModelForm): >   class Meta: >    

Ticket #15860: modelform.is_valid() and modelform.errors fail to anticipate database integrity errors, allows exceptions to reach the user

I hope it's OK to copy the body of the ticket here, even if it is redundant, in order to spur discussion. I'm willing to work on a patch if there is a consensus as to the proper solution... modelform.is_valid() fails to anticipate database integrity errors when those errors involve any fields

Ticket #15610 : Generic Foreign Keys break when used with multi-db.

http://code.djangoproject.com/ticket/15610 I just stumbled upon this unusual and problematic behavior, and thought that it might be worth a discussion. Details are in the ticket. Regards, Ed Gutierrez -- You received this message because you are subscribed to the Google Groups "Django

Re: django/db/models/sql/where.py: line 215

I'm afraid that I can't help you with the specific problem that you are describing, but I would like to recommend that you look at the work that Waldemar Kornewald and Thomas Wanschik are doing with their django-dbindexer:

Re: contrib.sites and multitenancy

Carl and I had a long discussion in IRC about all the issues he raises above. I am still digesting that conversation, but there are some things that already spring to mind. 1. I can see the merits of defining a SITE_BACKEND api that would allow users to choose from different site-retrieval

Re: contrib.sites and multitenancy

To complement the above list of locations where Site.objects.get_current is still in use, I have generated the following list of locations in the code where settings.SITE_ID continues to be in use: $ grep -nr SITE_ID * | grep -v svn | grep -v pyc conf/project_template/settings.py:39:SITE_ID = 1

Re: contrib.sites and multitenancy

I have added an initial, incomplete patch to the ticket for anyone who would like to comment on it: http://code.djangoproject.com/ticket/15089 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: contrib.sites and multitenancy

I have been researching changes required to implement this, and I thought I would share one of the sticky points. Some of this is relevant to Gabriel's recent post. I have been reading through revisions 14141 [1] and 14142 [2], which reversed some of the changes in revision 13980 [3], and I have

Re: #6375 -- Class Based Views: Opinions on commit plan

Thinking about it more, I think that the approach you took makes more sense. Regards, Eduardo On Oct 17, 7:49 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Mon, Oct 18, 2010 at 2:00 AM, legutierr <leguti...@gmail.com> wrote: > > > On Oct 17, 11:58 am, R

Re: #6375 -- Class Based Views: Opinions on commit plan

On Oct 17, 3:51 pm, Łukasz Rekucki wrote: > > Currently, you can override only how successful responses are > rendered. I'm going to try to work on this on my branch, but I have a > small problem: In number of places, views raise Http404 which then get > rendered by the

Re: #6375 -- Class Based Views: Opinions on commit plan

On Oct 17, 11:58 am, Russell Keith-Magee wrote: > On Sat, Oct 16, 2010 at 12:45 AM, Russell Keith-Magee > > I should also be able to port the tutorial before I commit -- which, > barring objection, I will do tomorrow night my time (about 24 hours > from now). Speak now,

Re: #6735 -- Class based generic views: call for comment

On Oct 5, 10:43 am, Jacob Kaplan-Moss wrote: > >  * Does django.views.generic.utils.coerce_put_post() indicate a change > > that needs to be made in Django? (Is there an existing ticket for > > this?) > > Yeah, this has been a wart in Django for a while -- Django doesn't >

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 1:04 pm, Andrew Godwin <and...@aeracode.org> wrote: > On 04/10/10 17:28, legutierr wrote: > > >    * First, treat data processing and retrieval as separable from > > rendering.  Create a bright line of separation between the two > > conceptual elements o

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 10:32 pm, Russell Keith-Magee wrote: > I completely agree that we don't want to rush this. The upside is that > if we *can* reach consensus, it isn't going to require a whole lot of > code changes; We're arguing about how to architect the base class, but > once