Re: Building a library of SQL functions into Django

On Friday, June 27, 2014 4:07:04 PM UTC+3, Michael Manfre wrote: > > If this is going to be moved off SQLCompiler, I think DatabaseOperations > is a better place for it because we already have > DatabaseOperatoins.combine_expression. The compile method will need access > to the compiler to match

Re: Building a library of SQL functions into Django

> If this is going to be moved off SQLCompiler, I think DatabaseOperations is a better place for it because we already have DatabaseOperatoins.combine_expression. The compile method will need access to the compiler to match the signature of as_sql (and it is necessary in some cases to inspect t

Re: Building a library of SQL functions into Django

On Mon, 2014-06-30 at 10:48 +0300, Josh Smeaton wrote: > So what kind of hook are we looking at here? Supplying a different > `.compile()` method that gets the node passed in? Won't that lead to > all kinds of isinstance checks to see if the compiler wants to change > the SQL of a particular node?

Re: Building a library of SQL functions into Django

>Still, I don't see *any* advantage of doing this compared to just providing the same implementation method in the node itself with the as_vendor syntax Me neither. I think I confused the subject when I brought up putting differences into the backend - but I was trying to highlight the differen

Re: Building a library of SQL functions into Django

On Mon, 2014-06-30 at 12:56 +0300, Josh Smeaton wrote: > >Still, I don't see *any* advantage of doing this compared to just > providing the same implementation method in the node itself with the > as_vendor syntax > > > Me neither. I think I confused the subject when I brought up putting > di

Re: Building a library of SQL functions into Django

FWIW I agree with Anssi Marc On 30 June 2014 12:00, Anssi Kääriäinen wrote: > On Mon, 2014-06-30 at 12:56 +0300, Josh Smeaton wrote: > > >Still, I don't see *any* advantage of doing this compared to just > > providing the same implementation method in the node itself with the > > as_vendor syn

Re: Migrations and Reusable Apps

Hey Aymeric, hey all, it took a little longer than I hoped but I eventually managed to put together a few questions that came up while porting a pluggable app to Django 1.7 with backward-compatibility through to 1.4. I hope all of these make sense and I am looking forward to the feedback: 1) Crea

Re: Migrations and Reusable Apps

Hi Andrew, hi Trey, as part of the migration to Django 1.7 I just mentioned in my post about the AppConfig, I've obviously also looked into migrations and I am a big fan :) For reference, the project in question is django-fancypages [1]. The route the I have taken for now is the same one describe

Re: Building a library of SQL functions into Django

+1, as_vendor() is IMO rather clean and expressive as a end user API. 3rd party backends are indeed a concern but we discussed this briefly on IRC today and I believe we have an acceptable solution for them, Josh is planning to write up about it. -- Loic On Monday, June 30, 2014 7:08:38 PM U

Re: Migrations and Reusable Apps

2014-06-30 14:32 GMT+02:00 Sebastian Vetter < sebast...@roadside-developer.com>: 1) Creating a subclass of AppConfig for a Django app is (according to > the docs) not required. If none is defined, Django falls back to AppConfig. > > For a pluggable app, is it recommended to always subclass AppCon

The 'rule'

Hi, I was about to start a discussion about a patch I'd like to contribute when I remembered there is a rule about contributions. Is it the '5 for 1' rule? Something like that - the regulars here will know immediately what it is I'm trying to remember! I did try and find it here: https://docs

Re: The 'rule' (five-for-one)

On 30 Jun 2014, at 12:01 PM, Andy Baker wrote: > I was about to start a discussion about a patch I'd like to contribute when I > remembered there is a rule about contributions. > > Is it the '5 for 1' rule? Something like that - the regulars here will know > immediately what it is I'm trying to

Re: Building a library of SQL functions into Django

This is how we think we can ask 3rd party backends to provide implementations for functions they need to modify: class DatabaseWrapper(BaseDatabaseWrapper): def __init__(self, *args, **kwargs): self.patch_functions() def patch_functions(self): """ all other fun

Re: The 'rule'

On Tue, Jul 1, 2014 at 3:01 AM, Andy Baker wrote: > Hi, > > I was about to start a discussion about a patch I'd like to contribute > when I remembered there is a rule about contributions. > > Is it the '5 for 1' rule? Something like that - the regulars here will > know immediately what it is I'm

Re: Support byte range requests in django.views.static.serve

Here is the commit for adding HTTP range support. I tested it in late versions of Chrome, Firefox, Opera and IE. https://github.com/satchamo/django/commit/2ce75c5c4bee2a858c0214d136bfcd351fcde11d The RangedFileReader class may be superfluous but I'm not aware of anything in Django or the Python

Re: Support byte range requests in django.views.static.serve

I'm actually +1 on the idea (I haven't looked at the patch). I use django-downloadview for streaming files which has support for the built in django server in development but testing that skipping/range works is impossible without deploying to a real web server. On Tuesday, 1 July 2014 11:20:28

Re: Migrations and Reusable Apps

Hey Aymeric, thanks a lot for your immediate feedback. I appreciate that a lot. I've added a few comments inline. On 30/06/14 23:55, Aymeric Augustin wrote: > 2014-06-30 14:32 GMT+02:00 Sebastian Vetter > >: > > 1) Creating a subclass of AppConfig fo

Re: Migrations and Reusable Apps

> Le 1 juil. 2014 à 04:46, Sebastian Vetter > a écrit : > > As far as I remember, the explicit import of models was discourage in > favour of get_model(). Is that no longer the case with the new app > registry? Do you see portential problems with explicit import and the > app registry initialis