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 =

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

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

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.

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

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

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

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

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

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