Re: Building a library of SQL functions into Django

[Anssi Kääriäinen]

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 the signature of as_sql (and it is necessary in 
> some cases to inspect the query).
>

+1 to both.

 
>
>> The main reason for offering a hook is that overriding SQLCompiler is a 
>> bit problematic. There exists various subclasses of SQLCompiler, and the 
>> backend needs to support those, too.
>>
>
> All of the subclasses are going to inherit SQLCompiler.compile and do the 
> same exact logic. I don't understand what problem is caused by overriding 
> compile that is solved by a function call to compile on some other class.
>

There are various subclasses of compiler in the standard ORM. A custom 
backend needs to provide all of them. The problem is best explained by 
looking at mysql/compiler.py: 
https://github.com/django/django/blob/master/django/db/backends/mysql/compiler.py.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/29ef8c3b-f2bf-412e-835d-67391b32dd10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Building a library of SQL functions into Django

[Josh Smeaton]

> 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 the query).

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? Can you maybe give me a brief example of what is 
wanted here if I've misunderstood above?

> There are various subclasses of compiler in the standard ORM. A custom 
backend needs to provide all of them. The problem is best explained by 
looking at mysql/compiler.py: 
https://github.com/django/django/blob/master/django/db/backends/mysql/compiler.py
.

Yes, but all of the other compilers inherit the default SQLCompiler, and 
will inherit the .compile method since they all subclass SQLCompiler. I 
think that's what Michael was getting at.

- Josh

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9f5bec33-23dc-4021-a7ec-2523c0722ba6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Building a library of SQL functions into Django

[Anssi Kääriäinen]

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? Can you maybe give me a brief example of
> what is wanted here if I've misunderstood above?

To me it seems there are two options - do isinstance() checks, or
provide a dictionary of class -> method. If you go with isinstance()
checks that could realistically lead to dozens of isinstance checks
chained in a long if-elif list.

The dictionary approach seems easier to support:

def compile(self, node, compiler):
if node.__class__ in self.node_implementations:
return self.node_implementation[node.__class__](
node, compiler, self.connection).

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. I don't know of any problem that is caused by using
as_vendor(), but avoided using backend specific .compile() hook.
Registering the as_vendor() methods has been the biggest complaint, but
that can be avoided by doing the registration on first __init__ of the
backend - there is no way SQL is going to be generated for given backend
without it being initialized first.

 -Anssi


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1404117241.9408.126.camel%40TTY32.
For more options, visit https://groups.google.com/d/optout.

Re: Building a library of SQL functions into Django

[Josh Smeaton]

>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 difference 
because it's not usually how django does things. If someone has an actual 
concern with the `as_vendor()` can you please mention it, and why. 
Otherwise I think we can proceed as-is with the as_vendor. Do you agree 
Anssi?

Josh

On Monday, 30 June 2014 18:28:10 UTC+10, Anssi Kääriäinen wrote:
>
> 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? Can you maybe give me a brief example of 
> > what is wanted here if I've misunderstood above? 
>
> To me it seems there are two options - do isinstance() checks, or 
> provide a dictionary of class -> method. If you go with isinstance() 
> checks that could realistically lead to dozens of isinstance checks 
> chained in a long if-elif list. 
>
> The dictionary approach seems easier to support: 
>
> def compile(self, node, compiler): 
> if node.__class__ in self.node_implementations: 
> return self.node_implementation[node.__class__]( 
> node, compiler, self.connection). 
>
> 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. I don't know of any problem that is caused by using 
> as_vendor(), but avoided using backend specific .compile() hook. 
> Registering the as_vendor() methods has been the biggest complaint, but 
> that can be avoided by doing the registration on first __init__ of the 
> backend - there is no way SQL is going to be generated for given backend 
> without it being initialized first. 
>
>  -Anssi 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/92b100f7-3daa-4e7b-ade6-7e8fa24ed046%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Building a library of SQL functions into Django

[Anssi Kääriäinen]

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
> differences into the backend - but I was trying to highlight the
> difference because it's not usually how django does things. If someone
> has an actual concern with the `as_vendor()` can you please mention
> it, and why. Otherwise I think we can proceed as-is with the
> as_vendor. Do you agree Anssi?

We can continue with as_vendor() no matter what the resolution is. We
already have the exact same problem for Lookups and Transforms, so we
aren't adding new problems by continuing with as_vendor().

Michael feels backend.ops.compile() is useful for django-mssql. Also,
multiple core developers think the as_vendor() syntax is bad because it
is monkey patching, or places 3rd party backends in unfair position. I
don't agree, but I don't see other core developers supporting my
position.

 - Anssi
> 
> 
> Josh
> 
> On Monday, 30 June 2014 18:28:10 UTC+10, Anssi Kääriäinen wrote:
> 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? Can you maybe give me a brief
> example of 
> > what is wanted here if I've misunderstood above? 
> 
> To me it seems there are two options - do isinstance() checks,
> or 
> provide a dictionary of class -> method. If you go with
> isinstance() 
> checks that could realistically lead to dozens of isinstance
> checks 
> chained in a long if-elif list. 
> 
> The dictionary approach seems easier to support: 
> 
> def compile(self, node, compiler): 
> if node.__class__ in self.node_implementations: 
> return self.node_implementation[node.__class__]( 
> node, compiler, self.connection). 
> 
> 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. I don't know of any problem that is caused
> by using 
> as_vendor(), but avoided using backend specific .compile()
> hook. 
> Registering the as_vendor() methods has been the biggest
> complaint, but 
> that can be avoided by doing the registration on first
> __init__ of the 
> backend - there is no way SQL is going to be generated for
> given backend 
> without it being initialized first. 
> 
>  -Anssi 
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to
> django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/92b100f7-3daa-4e7b-ade6-7e8fa24ed046%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1404126051.9408.155.camel%40TTY32.
For more options, visit https://groups.google.com/d/optout.

Re: Building a library of SQL functions into Django

[Marc Tamlyn]

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 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
> > difference because it's not usually how django does things. If someone
> > has an actual concern with the `as_vendor()` can you please mention
> > it, and why. Otherwise I think we can proceed as-is with the
> > as_vendor. Do you agree Anssi?
>
> We can continue with as_vendor() no matter what the resolution is. We
> already have the exact same problem for Lookups and Transforms, so we
> aren't adding new problems by continuing with as_vendor().
>
> Michael feels backend.ops.compile() is useful for django-mssql. Also,
> multiple core developers think the as_vendor() syntax is bad because it
> is monkey patching, or places 3rd party backends in unfair position. I
> don't agree, but I don't see other core developers supporting my
> position.
>
>  - Anssi
> >
> >
> > Josh
> >
> > On Monday, 30 June 2014 18:28:10 UTC+10, Anssi Kääriäinen wrote:
> > 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? Can you maybe give me a brief
> > example of
> > > what is wanted here if I've misunderstood above?
> >
> > To me it seems there are two options - do isinstance() checks,
> > or
> > provide a dictionary of class -> method. If you go with
> > isinstance()
> > checks that could realistically lead to dozens of isinstance
> > checks
> > chained in a long if-elif list.
> >
> > The dictionary approach seems easier to support:
> >
> > def compile(self, node, compiler):
> > if node.__class__ in self.node_implementations:
> > return self.node_implementation[node.__class__](
> > node, compiler, self.connection).
> >
> > 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. I don't know of any problem that is caused
> > by using
> > as_vendor(), but avoided using backend specific .compile()
> > hook.
> > Registering the as_vendor() methods has been the biggest
> > complaint, but
> > that can be avoided by doing the registration on first
> > __init__ of the
> > backend - there is no way SQL is going to be generated for
> > given backend
> > without it being initialized first.
> >
> >  -Anssi
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Django developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to django-developers+unsubscr...@googlegroups.com.
> > To post to this group, send email to
> > django-developers@googlegroups.com.
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/django-developers/92b100f7-3daa-4e7b-ade6-7e8fa24ed046%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1404126051.9408.155.camel%40TTY32
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1F2jfnUZaYL_z-ha5k1_fB1WjXFFQdSX_HhNdh1MeMrLw%40mail.gmail.com.
For more options, visit 

Re: Migrations and Reusable Apps

[Sebastian Vetter]

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) 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 AppConfig and
provide default_app_config?

2) The recommended way to register signals with receivers now (assuming
they should be registered automatically) is the ready() method.
Previously, the only "safe" way to ensure they would be connected was
doing that in the 'models.py'.

For a pluggable app this can be tricky if you are trying to maintain
backward-compatability. The only way I can think of is checking in the
'models.py' for a Django version < 1.7 and only run the code then. Is
there another/better way to do that?

3) Across several pluggable apps that I've worked on, there have been
several occasions where a model from one app is imported into the
'models.py' of another app. Now this causes issues with the new
AppConfig if I call 'get_model' at the module level. The only way I see
around it is to pull 'get_model' into that function(s) where this model
is used...which seems bad. An example would be here [1]. It might not be
the best example but one that I've come across just a few days ago.

Is there a better way to deal with this when using the AppConfig? Or
should that be avoided in general to import model in another apps'
'models.py'.

4) A project that I am working with is django-oscar [2] which defines an
'app.py' which contains a subclass of 'Application' (e.g. [3]). The main
purpose is to provide an overridable way to define URL pattners by
providing them through a 'get_urls' method.

It seems intuitive to me to consolidate functionality like that into the
AppConfig subclass for an app. Are there any reasons for or against
doing this? Are there any implications this might have on the loading of
the app registry?

Thanks for any thoughts and advice on this. And thanks for the great new
appregistry, it's a pleasure to work with.

Cheers,
Sebastian

PS: @Florian, thanks for the PGP/Mime hint. I hope it looks better this
time :)

[1]
https://github.com/tangentlabs/django-fancypages/blob/issue/33/support_for_django17/fancypages/models/blocks/content.py#L127
[2] https://github.com/tangentlabs/django-oscar
[3]
https://github.com/tangentlabs/django-oscar/blob/master/oscar/apps/basket/app.py



signature.asc
Description: OpenPGP digital signature

Re: Migrations and Reusable Apps

[Sebastian Vetter]

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 described in Trey's
blog post. Specifically variant 3) which uses 'migrations' for Django
migrations and 'south_migrations' for South. For now, I've documented
the setting 'SOUTH_MIGRATION_MODULES' as a requirement for pre-1.7
projects. This seems a good enough solution for now and I'm happy to
encourage people to move to Django 1.7 by making it a bit easier.

The one thing that I am currently struggling with a bit is how to ensure
consistency of both migrations whenever a model changes happens. Do you
have any suggestions on how to deal with that?

Is there a more sensible way than putting a couple of scripts together
that, e.g. run migrations in different Django version and then run tests
for migrations checking the schema of both. Any suggestions on that? I
might be overthinking this but I don't like it when I have to remember
these things...I'm bad at that.

Thanks for you input on this and thanks to Andrew and anyone who helped
getting this amazing migrations framework into Django 1.7!

-- 
Cheers,
Seb

[1] https://github.com/tangentlabs/django-fancypages



signature.asc
Description: OpenPGP digital signature

Re: Building a library of SQL functions into Django

[Loic Bistuer]

+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 UTC+7, Marc Tamlyn wrote:
>
> 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 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
>> > difference because it's not usually how django does things. If someone
>> > has an actual concern with the `as_vendor()` can you please mention
>> > it, and why. Otherwise I think we can proceed as-is with the
>> > as_vendor. Do you agree Anssi?
>>
>> We can continue with as_vendor() no matter what the resolution is. We
>> already have the exact same problem for Lookups and Transforms, so we
>> aren't adding new problems by continuing with as_vendor().
>>
>> Michael feels backend.ops.compile() is useful for django-mssql. Also,
>> multiple core developers think the as_vendor() syntax is bad because it
>> is monkey patching, or places 3rd party backends in unfair position. I
>> don't agree, but I don't see other core developers supporting my
>> position.
>>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/503f2fcb-48c6-484f-8309-2c76c5c7873f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations and Reusable Apps

[Aymeric Augustin]

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 AppConfig and
> provide default_app_config?
>

There are two reasons for doing that:

1) Provide a translatable verbose_name for the admin. If your application
doesn't have models, or if it isn't translated and the capitalised app_label
is what you need, this reason doesn't apply.

2) Run code at start-up. If your application does this, I would encourage
you to move it inside AppConfig.ready(), even if it works just fine at
module-level in models.py.

If neither matters for your application, don't bother with
default_app_config,
just use Django's default AppConfig.

2) The recommended way to register signals with receivers now (assuming
> they should be registered automatically) is the ready() method.
> Previously, the only "safe" way to ensure they would be connected was
> doing that in the 'models.py'.
>
> For a pluggable app this can be tricky if you are trying to maintain
> backward-compatability. The only way I can think of is checking in the
> 'models.py' for a Django version < 1.7 and only run the code then. Is
> there another/better way to do that?
>

That's the pattern I'm advocating. One may find explicit version checks
inelegant, but in practice they just work. For an example, see:
https://github.com/django-debug-toolbar/django-debug-toolbar/blob/master/debug_toolbar/models.py


> 3) Across several pluggable apps that I've worked on, there have been
> several occasions where a model from one app is imported into the
> 'models.py' of another app. Now this causes issues with the new
> AppConfig if I call 'get_model' at the module level. The only way I see
> around it is to pull 'get_model' into that function(s) where this model
> is used...which seems bad. An example would be here [1]. It might not be
> the best example but one that I've come across just a few days ago.
>
> Is there a better way to deal with this when using the AppConfig? Or
> should that be avoided in general to import model in another apps'
> 'models.py'.
>

You can import models from other apps explicitly:
from otherapp.models import SomeModel

What doesn't work is to obtain them through get_model().

This is often an issue with get_user_model(), which is just a shortcut for
get_model(settings.AUTH_USER_MODEL).

At this point, my best advice is to use string references eg. 'app.Model'
at import time and resolve them at runtime. That's how Django's custom
user models are implemented.

If you're asking with django-oscar in mind, I'm following closely the story
there. My team is currently building an Oscar shop. We're going live in
September and we'd like to do so on Django 1.7.

4) A project that I am working with is django-oscar [2] which defines an
> 'app.py' which contains a subclass of 'Application' (e.g. [3]). The main
> purpose is to provide an overridable way to define URL pattners by
> providing them through a 'get_urls' method.
>
> It seems intuitive to me to consolidate functionality like that into the
> AppConfig subclass for an app. Are there any reasons for or against
> doing this? Are there any implications this might have on the loading of
> the app registry?
>

I see this as a variant of the common suggestion of managing app-specific
settings in AppConfig classes. We might want to implement that at some
point. But I'd like to see how the dust settles on my refactoring first.

In the mean time, nothing prevents third-party apps from providing mixins
implementing that feature.

Regarding django-oscar, I have a hunch that its Application class should
subclass AppConfig on Django 1.7. But that would make it difficult to
support both 1.6 and 1.7 in the same release.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mWaBtxc1isWny2%3DSAgWt2OVck8kaRR%2BoHMKUAK24zS1jQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

The 'rule'

[Andy Baker]

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.djangoproject.com/en/1.7/internals/contributing/ but 
couldn't spot it. It's hard to search for something when you can't remember 
what it's called...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/30a19b80-7d77-4702-9a43-ff25b609553c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Wim Lewis]

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 remember!

I think the intent is more "If the committers haven't looked at your pet patch 
and you want them to, you can triage 5 tickets and ask for yours to be looked 
at in return". I don't think it's intended to keep people from contributing. On 
the other hand, I'm sure everyone would appreciate the help triaging tickets.

Original post from Jacob Kaplan-Moss:

http://python.6.x6.nabble.com/Help-review-tickets-get-a-prize-td511910.html


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0E676B4B-D9BF-40B6-BB9D-898067FA867F%40omnigroup.com.
For more options, visit https://groups.google.com/d/optout.

Re: Building a library of SQL functions into Django

[Josh Smeaton]

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 functions work correctly, so we just
need to patch Length
"""
from django.db.models.functions import Length
def new_length(self, compiler, connection):
self.function = 'LEN' # rather than 'LENGTH'
return self.as_sql(compiler, connection)
Length.as_mssql = new_length


I think this is rather elegant - patch what you need to, and leave 
everything else. It uses the same API we'd ask 3rd party libraries to use 
so there is no disconnect between libraries and backends. Anssi pointed out 
the DatabaseWrapper.__init__ method as the place of registration, since it 
will be run before any functions are created. Perhaps we could create a new 
method on DatabaseWrapper called `provide_function_implementations` that 
3rd party backends can override to effectively replace a custom 
`patch_functions`, but it'd really only be a "blessed" method used for 
documenting the agreed extension point.

Carl, Michael, and Aymeric, I'm interested in hearing your thoughts on 
this. Does this work for you?

Regards,

On Monday, 30 June 2014 23:16:17 UTC+10, Loic Bistuer wrote:
>
> +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 UTC+7, Marc Tamlyn wrote:
>>
>> 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 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
>>> > difference because it's not usually how django does things. If someone
>>> > has an actual concern with the `as_vendor()` can you please mention
>>> > it, and why. Otherwise I think we can proceed as-is with the
>>> > as_vendor. Do you agree Anssi?
>>>
>>> We can continue with as_vendor() no matter what the resolution is. We
>>> already have the exact same problem for Lookups and Transforms, so we
>>> aren't adding new problems by continuing with as_vendor().
>>>
>>> Michael feels backend.ops.compile() is useful for django-mssql. Also,
>>> multiple core developers think the as_vendor() syntax is bad because it
>>> is monkey patching, or places 3rd party backends in unfair position. I
>>> don't agree, but I don't see other core developers supporting my
>>> position.
>>>
>>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c9a18c56-97df-41bb-a35c-6d8a6114299e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The 'rule'

[Russell Keith-Magee]

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 trying to remember!
>
> I did try and find it here:
> https://docs.djangoproject.com/en/1.7/internals/contributing/ but
> couldn't spot it. It's hard to search for something when you can't remember
> what it's called...
>
> Hi Andy,

The 5-for-1 offer isn't an official part of the Django development process;
it's an ad-hoc thing that some members of the core team have offered from
time to time when they find themselves with some spare time.

I'm not aware of anyone on the core team that is currently offering 5-for-1
in a formal capacity. That said, if you drop into IRC and ask around, you
might find someone who will offer the deal, especially if you can find 5
tickets in a related area.

Yours
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq849nu9Ln_jrF_0ZM4qYp_rzvCxaiAFiM3d3eL9ZJjsZKuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[matt]

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 standard library that does something like that.

Feedback appreciated.

On Sunday, April 13, 2014 8:30:37 PM UTC-7, md...@pdx.edu wrote:
>
> Is the Django community interested in supporting HTTP range requests in 
> django.views.static.serve 
> ?
>
> The primary benefit I see is that it makes files served up for  and 
>  "seek-able" with the django server. This generally isn't a problem 
> for small files (except in Chrome 
> ), 
> but becomes an issue for larger ones.
>
> Werkzeug has a function that parses the range header 
> ,
>  
> which I used to support range requests in a Django application. I estimate 
> that robust support for HTTP range requests would cost <300 lines of code, 
> plus tests.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ce048851-9d85-4c94-a152-4e0bd617e815%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Josh Smeaton]

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 UTC+10, ma...@satchamo.com wrote:
>
> 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 standard library that does something like 
> that.
>
> Feedback appreciated.
>
> On Sunday, April 13, 2014 8:30:37 PM UTC-7, md...@pdx.edu wrote:
>>
>> Is the Django community interested in supporting HTTP range requests in 
>> django.views.static.serve 
>> ?
>>
>> The primary benefit I see is that it makes files served up for  
>> and  "seek-able" with the django server. This generally isn't a 
>> problem for small files (except in Chrome 
>> ), 
>> but becomes an issue for larger ones.
>>
>> Werkzeug has a function that parses the range header 
>> ,
>>  
>> which I used to support range requests in a Django application. I estimate 
>> that robust support for HTTP range requests would cost <300 lines of code, 
>> plus tests.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2b219239-c38d-4706-bc80-72dbeee9bc89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations and Reusable Apps

[Sebastian Vetter]

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 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 AppConfig and
> provide default_app_config?
> 
> 
> There are two reasons for doing that:
> 
> 1) Provide a translatable verbose_name for the admin. If your application
> doesn't have models, or if it isn't translated and the capitalised app_label
> is what you need, this reason doesn't apply.
> 
> 2) Run code at start-up. If your application does this, I would encourage
> you to move it inside AppConfig.ready(), even if it works just fine at
> module-level in models.py.
> 
> If neither matters for your application, don't bother with
> default_app_config,
> just use Django's default AppConfig.

That makes sense. I gues in practise this means defining a AppConfig
most of the time if just for reason 1).

> 2) The recommended way to register signals with receivers now (assuming
> they should be registered automatically) is the ready() method.
> Previously, the only "safe" way to ensure they would be connected was
> doing that in the 'models.py'.
> 
> For a pluggable app this can be tricky if you are trying to maintain
> backward-compatability. The only way I can think of is checking in the
> 'models.py' for a Django version < 1.7 and only run the code then. Is
> there another/better way to do that?
> 
> 
> That's the pattern I'm advocating. One may find explicit version checks
> inelegant, but in practice they just work. For an example, see:
> https://github.com/django-debug-toolbar/django-debug-toolbar/blob/master/debug_toolbar/models.py

Inelegant is the right word :) But I agree that it works and with a
deprecation on top of it they might not have to stick around for too long.

> 3) Across several pluggable apps that I've worked on, there have been
> several occasions where a model from one app is imported into the
> 'models.py' of another app. Now this causes issues with the new
> AppConfig if I call 'get_model' at the module level. The only way I see
> around it is to pull 'get_model' into that function(s) where this model
> is used...which seems bad. An example would be here [1]. It might not be
> the best example but one that I've come across just a few days ago.
> 
> Is there a better way to deal with this when using the AppConfig? Or
> should that be avoided in general to import model in another apps'
> 'models.py'.
> 
> 
> You can import models from other apps explicitly:
> from otherapp.models import SomeModel
>  
> What doesn't work is to obtain them through get_model().

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 initialisation?

> This is often an issue with get_user_model(), which is just a shortcut for
> get_model(settings.AUTH_USER_MODEL).
> 
> At this point, my best advice is to use string references eg. 'app.Model'
> at import time and resolve them at runtime. That's how Django's custom
> user models are implemented.
> 
> If you're asking with django-oscar in mind, I'm following closely the story
> there. My team is currently building an Oscar shop. We're going live in
> September and we'd like to do so on Django 1.7.

I'll be following that conversation closely. A few of the apps that I'm
maintaining/working on around Oscar are using similar patterns for
obvious reasons and the challenges/solutions are most likely to be the
same or similar.

> 4) A project that I am working with is django-oscar [2] which defines an
> 'app.py' which contains a subclass of 'Application' (e.g. [3]). The main
> purpose is to provide an overridable way to define URL pattners by
> providing them through a 'get_urls' method.
> 
> It seems intuitive to me to consolidate functionality like that into the
> AppConfig subclass for an app. Are there any reasons for or against
> doing this? Are there any implications this might have on the loading of
> the app registry?
> 
> 
> I see this as a variant of the common suggestion of managing app-specific
> settings in AppConfig classes. We might want to implement that at some
> point. But I'd like to see how the dust settles on my refactoring first.
>
> In the mean time, nothing prevents third-party apps from providing mixins
> implementing that feature.

That makes absolute sense. I mainly wanted to check that there isn't
anything in there or in the works that might make this difficult.

> Regarding django-oscar, I h

Re: Migrations and Reusable Apps

[Aymeric Augustin]

> 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 initialisation?

That only applies when you implement an AppConfig.ready() method,
in order to avoid a chicken'n'egg problem between apps and models.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9544415C-E17F-44F8-BAFA-627C33B6B4F8%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.