Re: Regression in ValidationError in 1.7

Hi Tim, My use case in practice is effectively this - in the clean() method for a form that has a 'code' field, plus a number of others: def clean(self): ... try: validate_code(self.instance, code) except ValidationError as e: self._errors = e.u

Re: APPEND_SLASH only 500's for POST, not for PUT/DELETE. Intentional?

We're talking about the check in CommonMiddleware right? Since it's done only if DEBUG is True, it seems to serve mostly as a courtesy to alert developers of the inability of redirects being able to preserve POST data. Thinking about it a bit more, as far as I know, DELETE requests don't typica

Re: APPEND_SLASH only 500's for POST, not for PUT/DELETE. Intentional?

> No, I don't think it's intentional -- more that Django wasn't initially built with REST APIs in mind. Makes sense. So would a pull request that includes tests and subjects PUT/DELETE to the same behavior as APPEND_SLASH be appreciated? I understand it's technically a breaking change, and some

Re: APPEND_SLASH only 500's for POST, not for PUT/DELETE. Intentional?

No, I don't think it's intentional -- more that Django wasn't initially built with REST APIs in mind. On Friday, June 27, 2014 2:13:10 PM UTC-4, Phill Tornroth wrote: > > Ran into this recently and it seemed counterintuitive. The APPEND_SLASH > functionality 500's for POST, but returns a 302 for

APPEND_SLASH only 500's for POST, not for PUT/DELETE. Intentional?

Ran into this recently and it seemed counterintuitive. The APPEND_SLASH functionality 500's for POST, but returns a 302 for PUT (and I assume DELETE after looking at the source). Is that intentional? It surprised me that POST/PUT/DELETE wouldn't all share behavior in this case. Thanks in advanc

Re: Building a library of SQL functions into Django

On 18 June 2014 12:39, Anssi Kääriäinen wrote: > On Wednesday, June 18, 2014 4:52:11 AM UTC+3, Josh Smeaton wrote: >> >> Over the last 6 months we've been working on a fairly large refactor to >> expressions. As a brief catch up, expressions are currently F() expressions. >> I've expanded their sc

Re: Regression in ValidationError in 1.7

Russ, could you include a code snippet of what no longer works? I think there is a documented solution that involves modifying Form._errors (see https://docs.djangoproject.com/en/1.6/ref/forms/validation/#django.forms.Form.clean), but I'm not sure if you're doing that or something different. Th

Re: Building a library of SQL functions into Django

On Fri, Jun 27, 2014 at 7:04 AM, Anssi Kääriäinen wrote: > This is possible to do by supplying a custom SQLCompiler class for the > backend, and overriding its .compile() method. > > Personally I don't see usage of as_vendor() as that problematic. Supplying > as_vendor in first DatabaseWrapper.__

Re: Regression in ValidationError in 1.7

On Fri, Jun 27, 2014 at 7:35 PM, Curtis Maloney wrote: > Am I reading this right as "people used to commonly solve this problem by > using an internal API, but now we have a public one... AND the old internal > API is now changed"? > > If so, the solution seems obvious -- document that it's time

Re: Regression in ValidationError in 1.7

Am I reading this right as "people used to commonly solve this problem by using an internal API, but now we have a public one... AND the old internal API is now changed"? If so, the solution seems obvious -- document that it's time to move the the official solution :) -- Curtis On 27 June 2014

Re: Building a library of SQL functions into Django

I agree that 3rd party backends should have a hook to provide their own customisations. I still think that the as_vendor approach is useful provided that the backend has a chance to register their customisations (where required - they still automatically use the default as_sql() method if there

Re: Changes to ORM expressions API

It seems the biggest worry right now is how 3rd party backends and users can alter the generated query string per backend. The current way is the same used for Lookups and Transforms, and those are in 1.7. So, I don't think we need to invent some other way for expressions. And, as Michael Manfr

Re: Regression in ValidationError in 1.7

Hi Russ, Good point and thanks for testing! For me, this should definitely be listed in the release notes and we should provide people a hint of how to fix it as well. IMO we do not need to support a non-documented feature. Wim On Friday, 27 June 2014 07:58:27 UTC+2, Russell Keith-Magee wro

Re: Building a library of SQL functions into Django

On Thursday, June 19, 2014 12:23:20 AM UTC+3, Carl Meyer wrote: > > On 06/18/2014 02:59 PM, Aymeric Augustin wrote: > > 2014-06-18 19:18 GMT+02:00 Carl Meyer > > >: > > > > If you need a Function in your > > project (whether provided by Django or by a third-