Re: Feature request: serve_file() view in static app

[Apostolos Bessas]

Hi Rivo,

So, if I understand this correctly, you need Django to figure out,
whether you need to serve the static HTML page or not.

In this case, you could use http://wiki.nginx.org/X-accel; that is,
return a HttpResponse with the X-Accel-Redirect header pointing to the
static file.

I suppose this is the most efficient way to serve static files only
when certain conditions are met (e.g. you need a permission check
first), without using Django to actually send the file.

I hope this helps.

Apostolis

On Tue, Jan 14, 2014 at 11:52 PM, Rivo Laks  wrote:
> Nono, I need Django for the API and backend logic :-)
>
> Let me illustrate my needs a bit better:
> - I have Django instance that serves API and a few related services and
> handles backend logic.
> - I also have nginx server in front of the Django instance, that also serves
> static files (css/js, which are always under /assets/ url prefix).
> - There are some url prefixes such as /api/* that have to be handled by the
> Django app.
> - All the other urls should be responded to with my static index.html file.
> Almost like a 404 handler that responds with static file.
>
> I suppose I could add all the prefixes that should be handled by the Django
> app into nginx config. Matching requests would then be forwarded to the
> Django app and all others would be handled by nginx.
> But I'd rather not do that, since then I'd have to also keep the nginx
> config in sync when I add another prefix to be handled by Django.
> The number of prefixes probably wouldn't hit double digits, so maybe it is
> the way to go, but I'm still wondering if there's a good way to handle it
> inside Django.
>
> Rivo
>
> teisipäev, 14. jaanuar 2014 23:02.43 UTC+2 kirjutas Aymeric Augustin:
>>
>> You don’t need an application server running Django to serve a file. A
>> plain and simple web server such as Apache or nginx will do.
>>
>> It’s a good practice to put application servers behind a web server acting
>> as a reverse proxy (and possibly load balancer), so you probably have one
>> already.
>>
>> It’s possible to serve the same page on any URL, it’s just a matter of
>> writing the appropriate configuration for the server you’re using.
>>
>> I hope this helps!
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 14 janv. 2014, at 21:18, Rivo Laks  wrote:
>>
>> Hm, indeed.
>>
>> Is there any better alternative or best practice for my usecase though?
>> Basically I want a view that responds with contents of a static file and
>> django.views.static.serve() does pretty much exactly that. Or is my usecase
>> just too fringe to be handled by Django core?
>>
>> Rivo
>>
>> esmaspäev, 13. jaanuar 2014 22:49.33 UTC+2 kirjutas Marc Tamlyn:
>>>
>>> `django.views.static.serve` is, in the words of the documentation,
>>> grossly inefficient and probably insecure, so it is unsuitable for
>>> production. Any attempt to make it more useful than its current use case
>>> (serving staticfiles in development) is unlikely to happen.
>>>
>>> Marc
>>>
>>>
>>> On 13 January 2014 20:39, Rivo Laks  wrote:

 Hi everyone,

 I'm proposing to split out from the django.views.static.serve() view the
 functionality to serve a single static file.
 The new view could be named serve_file(), would take request and
 fullpath as parameters and would serve the given file. The code would
 essentially be the second half of the current serve() view.
 The serve() view could then be modified to use serve_file(), once the
 fullpath has been found and isdir() check is done.

 My usecase:
 I'm writing a single-page javascript app, using Django for backend logic
 and API. The client side consists of js/css assets and a single html file. 
 I
 want that html file to be served by the Django app whenever a user makes a
 request to a url that doesn't match anything else (e.g. api urls). The
 javascript app does its own url routing, so if the user comes to  /foo/bar
 , the same html file is served and the javascript shows the right page to
 the user.
 ATM I've created a fallback view that contains copy-paste code from
 serve() and has the fullpath variable hardcoded. The reason I like serve()
 is that it contains some useful logic, such as being able to respond with
 304 (Not Modified) and setting some useful http headers.

 I can take care of creating a patch if the idea sounds good.

 Rivo


 --
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 

Re: Feature request: serve_file() view in static app

[Rivo Laks]

X-accel looks promising, I'll see if it can solve my problem. Thanks!

Rivo

teisipäev, 14. jaanuar 2014 23:58.13 UTC+2 kirjutas Marc Tamlyn:
>
> If you're on nginx, There are also some cases where you may find 
> X-ACCEL-REDIRECT useful, which allows you to return a blank HTTPResponse 
> from Django and tell nginx to serve a file.
>
> Nginx Docs: http://wiki.nginx.org/X-accel
> Blog post: 
> http://www.wellfireinteractive.com/blog/nginx-django-x-accel-redirects/
>
> In any case, this is now more suited to a Django-users discussion. If you 
> ask there, I'm sure there may be other possible solutions people know of.
>
> Thanks,
> Marc
>
>
> On 14 January 2014 21:52, Rivo Laks wrote:
>
>> Nono, I need Django for the API and backend logic :-)
>>
>> Let me illustrate my needs a bit better:
>> - I have Django instance that serves API and a few related services and 
>> handles backend logic.
>> - I also have nginx server in front of the Django instance, that also 
>> serves static files (css/js, which are always under /assets/ url prefix).
>> - There are some url prefixes such as /api/* that have to be handled by 
>> the Django app.
>> - All the other urls should be responded to with my static index.html 
>> file. Almost like a 404 handler that responds with static file.
>>
>> I suppose I could add all the prefixes that should be handled by the 
>> Django app into nginx config. Matching requests would then be forwarded to 
>> the Django app and all others would be handled by nginx.
>> But I'd rather not do that, since then I'd have to also keep the nginx 
>> config in sync when I add another prefix to be handled by Django.
>> The number of prefixes probably wouldn't hit double digits, so maybe it 
>> is the way to go, but I'm still wondering if there's a good way to handle 
>> it inside Django.
>>
>> Rivo
>>
>> teisipäev, 14. jaanuar 2014 23:02.43 UTC+2 kirjutas Aymeric Augustin:
>>>
>>> You don’t need an application server running Django to serve a file. A 
>>> plain and simple web server such as Apache or nginx will do.
>>>
>>> It’s a good practice to put application servers behind a web server 
>>> acting as a reverse proxy (and possibly load balancer), so you probably 
>>> have one already.
>>>
>>> It’s possible to serve the same page on any URL, it’s just a matter of 
>>> writing the appropriate configuration for the server you’re using.
>>>
>>> I hope this helps!
>>>
>>>  -- 
>>> Aymeric.
>>>
>>>
>>>  
>>> On 14 janv. 2014, at 21:18, Rivo Laks  wrote:
>>>
>>> Hm, indeed.
>>>
>>> Is there any better alternative or best practice for my usecase though? 
>>> Basically I want a view that responds with contents of a static file and 
>>> django.views.static.serve() does pretty much exactly that. Or is my usecase 
>>> just too fringe to be handled by Django core?
>>>
>>> Rivo
>>>
>>> esmaspäev, 13. jaanuar 2014 22:49.33 UTC+2 kirjutas Marc Tamlyn:

 `django.views.static.serve` is, in the words of the documentation, 
 grossly inefficient and probably insecure, so it is unsuitable for 
 production. Any attempt to make it more useful than its current use case 
 (serving staticfiles in development) is unlikely to happen.

 Marc


 On 13 January 2014 20:39, Rivo Laks  wrote:

> Hi everyone,
>
> I'm proposing to split out from the django.views.static.serve() view 
> the functionality to serve a single static file.
> The new view could be named serve_file(), would take request and 
> fullpath as parameters and would serve the given file. The code would 
> essentially be the second half of the current serve() view.
> The serve() view could then be modified to use serve_file(), once the 
> fullpath has been found and isdir() check is done.
>
> My usecase:
> I'm writing a single-page javascript app, using Django for backend 
> logic and API. The client side consists of js/css assets and a single 
> html 
> file. I want that html file to be served by the Django app whenever a 
> user 
> makes a request to a url that doesn't match anything else (e.g. api 
> urls). 
> The javascript app does its own url routing, so if the user comes to  
> /foo/bar  , the same html file is served and the javascript shows the 
> right 
> page to the user.
> ATM I've created a fallback view that contains copy-paste code from 
> serve() and has the fullpath variable hardcoded. The reason I like 
> serve() 
> is that it contains some useful logic, such as being able to respond with 
> 304 (Not Modified) and setting some useful http headers.
>
> I can take care of creating a patch if the idea sounds good.
>
> Rivo
>
>
> -- 
> 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 

Re: Testing parameters in database settings

[Michael Manfre]

On Tue, Jan 14, 2014 at 3:26 PM, Shai Berger  wrote:

>
> The way testing currently works is by creating a throw-away database,
> running
> the tests on that, and throwing it away. This means, among other things,
> that
> you need settings for a database service and credentials for a user that
> can
> create databases on this service. The common use-case is that this user is
> your "main" database user, and the service is your main service. Your
> suggestion, if I understand it correctly, gives the user two options:
>
> 1) Use separate credentials, and perhaps even a separate service, for
> testing;
> this implies that the test database stays alive all the time.
>

As it stands, the privileges for running the tests are greater than those
needed to run syncdb (or runserver), so I'm not sure what point you are
trying to make. If you want to be able to use only one set of credentials
to do everything, then you're going to use a user with enough privileges to
do everything. This assumes you're not using Oracle and need to provide the
slew of other configuration values, which should really be moved to OPTIONS.

2) Write configurations with repetitions or some other awkwardness, e.g.
>
> default_db = {
> 'ENGINE': 'this',
> 'HOST': 'that',
> 'NAME': 'the_other',
> 'USER': 'me',
> 'PASSWORD': 'my secret',
> }
>
> DATABASES = {
> 'default' : default_db,
> 'test_default' : dict(default_db,
> NAME='test_the_other',
> IS_TEST=True),
> }
>
> I don't see that as an improvement; you seem to be optimizing for the edge
> case at the expense of the common case.
>

This is not what I envisioned. By separate aliases, I don't mean to just
add more test aliases in with your existing settings. What I mean is that
each database alias defined in a settings file should define a single
connection configuration, not potentially two different configurations. If
you need a different configuration for testing, put them in a separate
configuration file.

 Example:

# settings.py - for local development
DATABASES = {
'default': {
'ENGINE': 'oracle',
 'NAME': 'my_db',
'USER': 'my_user', # user can syncdb, but database exists
 ...
# 'CAN_USE_FOR_TESTS': False, # Protect database from unit test trampling
  }
}


# test_settings.py - for unit tests
DATABASES = {
'default': {
'ENGINE': 'oracle',
 'NAME': 'test_my_db', # This was TEST_NAME
'USER': 'dba_user', # This is a user with proper credentials to drop a
database
 ...
'OPTIONS': {
# backend specific settings belong here
 'TEST_CREATE': True,
'TEST_TBLSPACE': 'test_',
'CHARSET': 'utf-8', # Or leave named as TEST_CHARSET
 ...
},
'CAN_USE_FOR_TESTS': True, # DB is safe to trample with tests
 }
}

Regards,
Michael Manfre

-- 
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/CAGdCwBvFLOykSGUByx67gtST%2BThFbhdavUHKeWJwYOVNjXKMcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: serve_file() view in static app

[Marc Tamlyn]

If you're on nginx, There are also some cases where you may find
X-ACCEL-REDIRECT useful, which allows you to return a blank HTTPResponse
from Django and tell nginx to serve a file.

Nginx Docs: http://wiki.nginx.org/X-accel
Blog post:
http://www.wellfireinteractive.com/blog/nginx-django-x-accel-redirects/

In any case, this is now more suited to a Django-users discussion. If you
ask there, I'm sure there may be other possible solutions people know of.

Thanks,
Marc


On 14 January 2014 21:52, Rivo Laks  wrote:

> Nono, I need Django for the API and backend logic :-)
>
> Let me illustrate my needs a bit better:
> - I have Django instance that serves API and a few related services and
> handles backend logic.
> - I also have nginx server in front of the Django instance, that also
> serves static files (css/js, which are always under /assets/ url prefix).
> - There are some url prefixes such as /api/* that have to be handled by
> the Django app.
> - All the other urls should be responded to with my static index.html
> file. Almost like a 404 handler that responds with static file.
>
> I suppose I could add all the prefixes that should be handled by the
> Django app into nginx config. Matching requests would then be forwarded to
> the Django app and all others would be handled by nginx.
> But I'd rather not do that, since then I'd have to also keep the nginx
> config in sync when I add another prefix to be handled by Django.
> The number of prefixes probably wouldn't hit double digits, so maybe it is
> the way to go, but I'm still wondering if there's a good way to handle it
> inside Django.
>
> Rivo
>
> teisipäev, 14. jaanuar 2014 23:02.43 UTC+2 kirjutas Aymeric Augustin:
>>
>> You don’t need an application server running Django to serve a file. A
>> plain and simple web server such as Apache or nginx will do.
>>
>> It’s a good practice to put application servers behind a web server
>> acting as a reverse proxy (and possibly load balancer), so you probably
>> have one already.
>>
>> It’s possible to serve the same page on any URL, it’s just a matter of
>> writing the appropriate configuration for the server you’re using.
>>
>> I hope this helps!
>>
>>  --
>> Aymeric.
>>
>>
>>
>> On 14 janv. 2014, at 21:18, Rivo Laks  wrote:
>>
>> Hm, indeed.
>>
>> Is there any better alternative or best practice for my usecase though?
>> Basically I want a view that responds with contents of a static file and
>> django.views.static.serve() does pretty much exactly that. Or is my usecase
>> just too fringe to be handled by Django core?
>>
>> Rivo
>>
>> esmaspäev, 13. jaanuar 2014 22:49.33 UTC+2 kirjutas Marc Tamlyn:
>>>
>>> `django.views.static.serve` is, in the words of the documentation,
>>> grossly inefficient and probably insecure, so it is unsuitable for
>>> production. Any attempt to make it more useful than its current use case
>>> (serving staticfiles in development) is unlikely to happen.
>>>
>>> Marc
>>>
>>>
>>> On 13 January 2014 20:39, Rivo Laks  wrote:
>>>
 Hi everyone,

 I'm proposing to split out from the django.views.static.serve() view
 the functionality to serve a single static file.
 The new view could be named serve_file(), would take request and
 fullpath as parameters and would serve the given file. The code would
 essentially be the second half of the current serve() view.
 The serve() view could then be modified to use serve_file(), once the
 fullpath has been found and isdir() check is done.

 My usecase:
 I'm writing a single-page javascript app, using Django for backend
 logic and API. The client side consists of js/css assets and a single html
 file. I want that html file to be served by the Django app whenever a user
 makes a request to a url that doesn't match anything else (e.g. api urls).
 The javascript app does its own url routing, so if the user comes to
 /foo/bar  , the same html file is served and the javascript shows the right
 page to the user.
 ATM I've created a fallback view that contains copy-paste code from
 serve() and has the fullpath variable hardcoded. The reason I like serve()
 is that it contains some useful logic, such as being able to respond with
 304 (Not Modified) and setting some useful http headers.

 I can take care of creating a patch if the idea sounds good.

 Rivo


 --
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@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/5d9f0449-2b46-4c50-81f5-
 

Re: Feature request: serve_file() view in static app

[Rivo Laks]

Nono, I need Django for the API and backend logic :-)

Let me illustrate my needs a bit better:
- I have Django instance that serves API and a few related services and 
handles backend logic.
- I also have nginx server in front of the Django instance, that also 
serves static files (css/js, which are always under /assets/ url prefix).
- There are some url prefixes such as /api/* that have to be handled by the 
Django app.
- All the other urls should be responded to with my static index.html file. 
Almost like a 404 handler that responds with static file.

I suppose I could add all the prefixes that should be handled by the Django 
app into nginx config. Matching requests would then be forwarded to the 
Django app and all others would be handled by nginx.
But I'd rather not do that, since then I'd have to also keep the nginx 
config in sync when I add another prefix to be handled by Django.
The number of prefixes probably wouldn't hit double digits, so maybe it is 
the way to go, but I'm still wondering if there's a good way to handle it 
inside Django.

Rivo

teisipäev, 14. jaanuar 2014 23:02.43 UTC+2 kirjutas Aymeric Augustin:
>
> You don’t need an application server running Django to serve a file. A 
> plain and simple web server such as Apache or nginx will do.
>
> It’s a good practice to put application servers behind a web server acting 
> as a reverse proxy (and possibly load balancer), so you probably have one 
> already.
>
> It’s possible to serve the same page on any URL, it’s just a matter of 
> writing the appropriate configuration for the server you’re using.
>
> I hope this helps!
>
> -- 
> Aymeric.
>
>
>  
> On 14 janv. 2014, at 21:18, Rivo Laks  
> wrote:
>
> Hm, indeed.
>
> Is there any better alternative or best practice for my usecase though? 
> Basically I want a view that responds with contents of a static file and 
> django.views.static.serve() does pretty much exactly that. Or is my usecase 
> just too fringe to be handled by Django core?
>
> Rivo
>
> esmaspäev, 13. jaanuar 2014 22:49.33 UTC+2 kirjutas Marc Tamlyn:
>>
>> `django.views.static.serve` is, in the words of the documentation, 
>> grossly inefficient and probably insecure, so it is unsuitable for 
>> production. Any attempt to make it more useful than its current use case 
>> (serving staticfiles in development) is unlikely to happen.
>>
>> Marc
>>
>>
>> On 13 January 2014 20:39, Rivo Laks  wrote:
>>
>>> Hi everyone,
>>>
>>> I'm proposing to split out from the django.views.static.serve() view the 
>>> functionality to serve a single static file.
>>> The new view could be named serve_file(), would take request and 
>>> fullpath as parameters and would serve the given file. The code would 
>>> essentially be the second half of the current serve() view.
>>> The serve() view could then be modified to use serve_file(), once the 
>>> fullpath has been found and isdir() check is done.
>>>
>>> My usecase:
>>> I'm writing a single-page javascript app, using Django for backend logic 
>>> and API. The client side consists of js/css assets and a single html file. 
>>> I want that html file to be served by the Django app whenever a user makes 
>>> a request to a url that doesn't match anything else (e.g. api urls). The 
>>> javascript app does its own url routing, so if the user comes to  /foo/bar  
>>> , the same html file is served and the javascript shows the right page to 
>>> the user.
>>> ATM I've created a fallback view that contains copy-paste code from 
>>> serve() and has the fullpath variable hardcoded. The reason I like serve() 
>>> is that it contains some useful logic, such as being able to respond with 
>>> 304 (Not Modified) and setting some useful http headers.
>>>
>>> I can take care of creating a patch if the idea sounds good.
>>>
>>> Rivo
>>>
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/5d9f0449-2b46-4c50-81f5-3b2e43e16512%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> 

Re: Feature request: serve_file() view in static app

[Aymeric Augustin]

You don’t need an application server running Django to serve a file. A plain 
and simple web server such as Apache or nginx will do.

It’s a good practice to put application servers behind a web server acting as a 
reverse proxy (and possibly load balancer), so you probably have one already.

It’s possible to serve the same page on any URL, it’s just a matter of writing 
the appropriate configuration for the server you’re using.

I hope this helps!

-- 
Aymeric.



On 14 janv. 2014, at 21:18, Rivo Laks  wrote:

> Hm, indeed.
> 
> Is there any better alternative or best practice for my usecase though? 
> Basically I want a view that responds with contents of a static file and 
> django.views.static.serve() does pretty much exactly that. Or is my usecase 
> just too fringe to be handled by Django core?
> 
> Rivo
> 
> esmaspäev, 13. jaanuar 2014 22:49.33 UTC+2 kirjutas Marc Tamlyn:
> `django.views.static.serve` is, in the words of the documentation, grossly 
> inefficient and probably insecure, so it is unsuitable for production. Any 
> attempt to make it more useful than its current use case (serving staticfiles 
> in development) is unlikely to happen.
> 
> Marc
> 
> 
> On 13 January 2014 20:39, Rivo Laks  wrote:
> Hi everyone,
> 
> I'm proposing to split out from the django.views.static.serve() view the 
> functionality to serve a single static file.
> The new view could be named serve_file(), would take request and fullpath as 
> parameters and would serve the given file. The code would essentially be the 
> second half of the current serve() view.
> The serve() view could then be modified to use serve_file(), once the 
> fullpath has been found and isdir() check is done.
> 
> My usecase:
> I'm writing a single-page javascript app, using Django for backend logic and 
> API. The client side consists of js/css assets and a single html file. I want 
> that html file to be served by the Django app whenever a user makes a request 
> to a url that doesn't match anything else (e.g. api urls). The javascript app 
> does its own url routing, so if the user comes to  /foo/bar  , the same html 
> file is served and the javascript shows the right page to the user.
> ATM I've created a fallback view that contains copy-paste code from serve() 
> and has the fullpath variable hardcoded. The reason I like serve() is that it 
> contains some useful logic, such as being able to respond with 304 (Not 
> Modified) and setting some useful http headers.
> 
> I can take care of creating a patch if the idea sounds good.
> 
> Rivo
> 
> 
> -- 
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/5d9f0449-2b46-4c50-81f5-3b2e43e16512%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> -- 
> 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/9db7ff84-8d44-4a03-b426-0af9e043d150%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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/5934A018-A873-4B1D-9BF9-7C27DF3E62E7%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing parameters in database settings

[Shai Berger]

Hi,

On Tuesday 14 January 2014 21:35:04 Michael Manfre wrote:

> Why are we not encouraging people to define different aliases for testing?
> Many of those TEST_ settings could be given meaning to the database
> configuration without being specific to running tests. Several of those
> TEST_ settings would no longer be necessary and several more would be
> properly rooted under OPTIONS because they are specific to a database's
> connection.
> 

The way testing currently works is by creating a throw-away database, running 
the tests on that, and throwing it away. This means, among other things, that 
you need settings for a database service and credentials for a user that can 
create databases on this service. The common use-case is that this user is 
your "main" database user, and the service is your main service. Your 
suggestion, if I understand it correctly, gives the user two options:

1) Use separate credentials, and perhaps even a separate service, for testing; 
this implies that the test database stays alive all the time.
2) Write configurations with repetitions or some other awkwardness, e.g.

default_db = {
'ENGINE': 'this',
'HOST': 'that',
'NAME': 'the_other',
'USER': 'me',
'PASSWORD': 'my secret',
}

DATABASES = {
'default' : default_db,
'test_default' : dict(default_db,
NAME='test_the_other',
IS_TEST=True),
}

I don't see that as an improvement; you seem to be optimizing for the edge 
case at the expense of the common case.

In particular, the explosion of TEST_* settings for Oracle all have to do with 
the creation of a new user and tablespace; in the scenario where the user is 
created for the test and deleted at its end, your suggestion doesn't seem to 
make much sense -- normal connections don't deal with it, and the test 
connection needs a "dba" connection to start from.

If I have misunderstood your suggestion, please clarify.

Thanks,
Shai.

-- 
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/201401142226.50182.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: serve_file() view in static app

[Rivo Laks]

Hm, indeed.

Is there any better alternative or best practice for my usecase though? 
Basically I want a view that responds with contents of a static file and 
django.views.static.serve() does pretty much exactly that. Or is my usecase 
just too fringe to be handled by Django core?

Rivo

esmaspäev, 13. jaanuar 2014 22:49.33 UTC+2 kirjutas Marc Tamlyn:
>
> `django.views.static.serve` is, in the words of the documentation, grossly 
> inefficient and probably insecure, so it is unsuitable for production. Any 
> attempt to make it more useful than its current use case (serving 
> staticfiles in development) is unlikely to happen.
>
> Marc
>
>
> On 13 January 2014 20:39, Rivo Laks wrote:
>
>> Hi everyone,
>>
>> I'm proposing to split out from the django.views.static.serve() view the 
>> functionality to serve a single static file.
>> The new view could be named serve_file(), would take request and fullpath 
>> as parameters and would serve the given file. The code would essentially be 
>> the second half of the current serve() view.
>> The serve() view could then be modified to use serve_file(), once the 
>> fullpath has been found and isdir() check is done.
>>
>> My usecase:
>> I'm writing a single-page javascript app, using Django for backend logic 
>> and API. The client side consists of js/css assets and a single html file. 
>> I want that html file to be served by the Django app whenever a user makes 
>> a request to a url that doesn't match anything else (e.g. api urls). The 
>> javascript app does its own url routing, so if the user comes to  /foo/bar  
>> , the same html file is served and the javascript shows the right page to 
>> the user.
>> ATM I've created a fallback view that contains copy-paste code from 
>> serve() and has the fullpath variable hardcoded. The reason I like serve() 
>> is that it contains some useful logic, such as being able to respond with 
>> 304 (Not Modified) and setting some useful http headers.
>>
>> I can take care of creating a patch if the idea sounds good.
>>
>> Rivo
>>
>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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/5d9f0449-2b46-4c50-81f5-3b2e43e16512%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
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/9db7ff84-8d44-4a03-b426-0af9e043d150%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing parameters in database settings

[Michael Manfre]

I'm -0, on sweeping this explosion of settings (mostly for Oracle) under a
"TEST" rug, instead of addressing the underlying problem. The entire TEST_*
collection of settings is, in my opinion, a broken design that is used to
shim a second "test" database configuration in a spot designed for a single
database configuration.

Why are we not encouraging people to define different aliases for testing?
Many of those TEST_ settings could be given meaning to the database
configuration without being specific to running tests. Several of those
TEST_ settings would no longer be necessary and several more would be
properly rooted under OPTIONS because they are specific to a database's
connection.

The only real benefit I see from the current implementation is that
TEST_NAME defaults to a prefixed name that should help reduce the chance of
mangling a production database. I'd rather see a top level TEST_DATABASES
or a IS_TEST_DATABASE (default False) key added to maintain that small
amount of configuration safety.

Regards,
Michael Manfre


On Tue, Jan 14, 2014 at 12:04 PM, Shai Berger  wrote:

> Hi all,
>
> Django's database settings currently support eleven separate parameters for
> testing, all named 'TEST_*', most of them more-or-less backend-specific (in
> fact, six -- already a majority -- are Oracle-specific). We have now
> discovered[1] that we need even more Oracle-test-specific parameters, for
> better control of the creation of the test tablespaces; I suppose there
> could
> be parallels for those in the other backends (for creation of test
> databases,
> the similar-but-not-equivalent feature).
>
> In my opinion, this is beginning to smell; I'd like to collect all these
> parameters into their own sub-dictionary, perhaps named "TESTING"; this
> is, of
> course, not backwards-compatible, and I'd like to hear your opinions. An
> alternative is to do something just for Oracle, but that would be a little
> odd
> IMO.
>
> The settings that may be affected are:
>
> Non-backend-specific:
>
> TEST_DEPENDENCIES
> TEST_MIRROR
>
> Different semantics on different backends:
>
> TEST_NAME[2]
>
> MySQL:
>
> TEST_CHARSET[3]
> TEST_COLLATION
>
> PostgreSQL:
>
> TEST_CHARSET[3]
>
> Oracle:
>
> TEST_USER_CREATE
> TEST_USER
> TEST_PASSWD
> TEST_CREATE
> TEST_TBLSPACE
> TEST_TBLSPACE_TMP
>
> For the curious-but-lazy, the Oracle settings are needed because Oracle
> does
> not do "databases" like other backends do, and so the testing framework
> needs
> a test user and a test tablespace; the TEST_{USER_,}CREATE settigns are
> booleans that control if these will be created for the test or just used.
> The
> parameters I want to add now, following #21775[1], would specify the exact
> location for the test tablespace files, and their initial and maximum
> sizes.
>
> Opinions?
>
> Thanks,
> Shai.
>
> [1] https://code.djangoproject.com/ticket/21775
>
> [2] On SQLite, the defualt is to use in-memory database (":memory:"), on
> others ('test_' + name); on Oracle the setting is used only for reporting
> to
> the user, and has no effect on the database used.
>
> [3] The name TEST_CHARSET is common to MySQL and PostgreSQL, but the
> appropriate values are backend-specific.
>
> --
> 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/201401141904.43630.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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/CAGdCwBvJGSgOExDac5P511gqPgg6FPTt654gjNptqkCqC-2faA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: permit global change of BaseForm.label_suffix

[Shai Berger]

On Saturday 11 January 2014 19:34:42 Tilman Koschnick wrote:
> Hi,
> 
> I'd like to bring up #18133 again, which has been closed as wontfix.
> 
> I am looking for an easy and non-intrusive way to override the default
> colon suffix on form field labels. The suggested methods of subclassing
> the affected Form classes leads to quite a bit of code churn. I am using
> Forms and ModelForms, as well as contrib and other 3rd party forms in my
> projects.
> 
> Making the default suffix a class attribute allows to override it
> globally by re-setting it early, before any forms are instantiated:
> 
> from django.forms import BaseForm
> BaseForm.DEFAULT_LABEL_SUFFIX = ''
> 

This is monkeypatching; if you're willing to do that, you should have no 
problem with doing, at the same place,


from django.forms import BaseForm
orig_init = BaseForm.__init__
def BaseForm_init(*args, **kwargs):
kwargs.setdefault("label_suffix", "")
orig_init(*args, **kwargs)
BaseForm.__init__ = BaseForm_init

(caveat: untested, may require some messing to make work)

This does not require any change to Django.

HTH,
Shai.

-- 
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/201401142124.07735.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing parameters in database settings

[Marc Tamlyn]

+1, what Aymeric said.
On 14 Jan 2014 17:50, "Aymeric Augustin" 
wrote:

> This has bugged be for some time too. Fix it!
>
> Even if it's just for tests it would be nice to implement a simple
> deprecation path.
>
> I'd simply call the new key TEST, but whoever writes the patch can choose
> the name :-)
>
> --
> Aymeric.
>
>
>
> 2014/1/14 Shai Berger 
>
>> Hi all,
>>
>> Django's database settings currently support eleven separate parameters
>> for
>> testing, all named 'TEST_*', most of them more-or-less backend-specific
>> (in
>> fact, six -- already a majority -- are Oracle-specific). We have now
>> discovered[1] that we need even more Oracle-test-specific parameters, for
>> better control of the creation of the test tablespaces; I suppose there
>> could
>> be parallels for those in the other backends (for creation of test
>> databases,
>> the similar-but-not-equivalent feature).
>>
>> In my opinion, this is beginning to smell; I'd like to collect all these
>> parameters into their own sub-dictionary, perhaps named "TESTING"; this
>> is, of
>> course, not backwards-compatible, and I'd like to hear your opinions. An
>> alternative is to do something just for Oracle, but that would be a
>> little odd
>> IMO.
>>
>> The settings that may be affected are:
>>
>> Non-backend-specific:
>>
>> TEST_DEPENDENCIES
>> TEST_MIRROR
>>
>> Different semantics on different backends:
>>
>> TEST_NAME[2]
>>
>> MySQL:
>>
>> TEST_CHARSET[3]
>> TEST_COLLATION
>>
>> PostgreSQL:
>>
>> TEST_CHARSET[3]
>>
>> Oracle:
>>
>> TEST_USER_CREATE
>> TEST_USER
>> TEST_PASSWD
>> TEST_CREATE
>> TEST_TBLSPACE
>> TEST_TBLSPACE_TMP
>>
>> For the curious-but-lazy, the Oracle settings are needed because Oracle
>> does
>> not do "databases" like other backends do, and so the testing framework
>> needs
>> a test user and a test tablespace; the TEST_{USER_,}CREATE settigns are
>> booleans that control if these will be created for the test or just used.
>> The
>> parameters I want to add now, following #21775[1], would specify the exact
>> location for the test tablespace files, and their initial and maximum
>> sizes.
>>
>> Opinions?
>>
>> Thanks,
>> Shai.
>>
>> [1] https://code.djangoproject.com/ticket/21775
>>
>> [2] On SQLite, the defualt is to use in-memory database (":memory:"), on
>> others ('test_' + name); on Oracle the setting is used only for reporting
>> to
>> the user, and has no effect on the database used.
>>
>> [3] The name TEST_CHARSET is common to MySQL and PostgreSQL, but the
>> appropriate values are backend-specific.
>>
>> --
>> 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/201401141904.43630.shai%40platonix.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> 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-7mVYNJJiYJBdRAy17rgJV0hRh31fkd%3DMzF30kJOgoU3MMg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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/CAMwjO1G6TyQ0WWc%3D13fVTRoLUhL29xths55W7LRjPi0pTyNLHg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing parameters in database settings

[Aymeric Augustin]

This has bugged be for some time too. Fix it!

Even if it's just for tests it would be nice to implement a simple
deprecation path.

I'd simply call the new key TEST, but whoever writes the patch can choose
the name :-)

-- 
Aymeric.



2014/1/14 Shai Berger 

> Hi all,
>
> Django's database settings currently support eleven separate parameters for
> testing, all named 'TEST_*', most of them more-or-less backend-specific (in
> fact, six -- already a majority -- are Oracle-specific). We have now
> discovered[1] that we need even more Oracle-test-specific parameters, for
> better control of the creation of the test tablespaces; I suppose there
> could
> be parallels for those in the other backends (for creation of test
> databases,
> the similar-but-not-equivalent feature).
>
> In my opinion, this is beginning to smell; I'd like to collect all these
> parameters into their own sub-dictionary, perhaps named "TESTING"; this
> is, of
> course, not backwards-compatible, and I'd like to hear your opinions. An
> alternative is to do something just for Oracle, but that would be a little
> odd
> IMO.
>
> The settings that may be affected are:
>
> Non-backend-specific:
>
> TEST_DEPENDENCIES
> TEST_MIRROR
>
> Different semantics on different backends:
>
> TEST_NAME[2]
>
> MySQL:
>
> TEST_CHARSET[3]
> TEST_COLLATION
>
> PostgreSQL:
>
> TEST_CHARSET[3]
>
> Oracle:
>
> TEST_USER_CREATE
> TEST_USER
> TEST_PASSWD
> TEST_CREATE
> TEST_TBLSPACE
> TEST_TBLSPACE_TMP
>
> For the curious-but-lazy, the Oracle settings are needed because Oracle
> does
> not do "databases" like other backends do, and so the testing framework
> needs
> a test user and a test tablespace; the TEST_{USER_,}CREATE settigns are
> booleans that control if these will be created for the test or just used.
> The
> parameters I want to add now, following #21775[1], would specify the exact
> location for the test tablespace files, and their initial and maximum
> sizes.
>
> Opinions?
>
> Thanks,
> Shai.
>
> [1] https://code.djangoproject.com/ticket/21775
>
> [2] On SQLite, the defualt is to use in-memory database (":memory:"), on
> others ('test_' + name); on Oracle the setting is used only for reporting
> to
> the user, and has no effect on the database used.
>
> [3] The name TEST_CHARSET is common to MySQL and PostgreSQL, but the
> appropriate values are backend-specific.
>
> --
> 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/201401141904.43630.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
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-7mVYNJJiYJBdRAy17rgJV0hRh31fkd%3DMzF30kJOgoU3MMg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Django Security & OWASP Project

[Michael Coates]

Django Developers,

Hello! Over at OWASP I've started a framework security project. Our goal is 
to capture the security posture, options and capabilities of different 
frameworks. Through this we can educate developers on how to enable 
security controls in the framework and also work with frameworks to gain 
adoption of any missing capabilities.

When I was leading the security team at Mozilla we worked with Django a 
ton. You guys have always been on the leading edge of framework security. 
It was an easy choice to start with Django for the OWASP framework security 
project.

Would any of you be interested in helping out with our project?

Ways to help:
1. Information gathering - we're putting together a standard list of 
security controls in frameworks and django's support (we'll move to other 
frameworks with this model). You can provide info here:
https://docs.google.com/a/owasp.org/spreadsheet/ccc?key=0AhSfMVkfLvsldEltRUEwMkUydVVrMkNyVW1vbGxLaXc#gid=0

- Please suggest additional security controls we should have in column A
- We also need to capture if Django supports the different controls, the 
version added, default options, etc

2. Assistance with adding missing controls
This will come later, but if we find any missing controls it would be great 
to understand the best way to work together to get them added.

3. Join the mailing list
https://lists.owasp.org/mailman/listinfo/owasp_framework_security_project

Any thoughts or ideas are welcomed. We're in the beginning and will 
continue to flush out the project as we go.



Thanks!

--
Michael Coates
@_mwc

-- 
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/d5305915-8298-465a-bc8a-ec2df73b3587%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Testing parameters in database settings

[Shai Berger]

Hi all,

Django's database settings currently support eleven separate parameters for 
testing, all named 'TEST_*', most of them more-or-less backend-specific (in 
fact, six -- already a majority -- are Oracle-specific). We have now 
discovered[1] that we need even more Oracle-test-specific parameters, for 
better control of the creation of the test tablespaces; I suppose there could 
be parallels for those in the other backends (for creation of test databases, 
the similar-but-not-equivalent feature). 

In my opinion, this is beginning to smell; I'd like to collect all these 
parameters into their own sub-dictionary, perhaps named "TESTING"; this is, of 
course, not backwards-compatible, and I'd like to hear your opinions. An 
alternative is to do something just for Oracle, but that would be a little odd 
IMO.

The settings that may be affected are:

Non-backend-specific:

TEST_DEPENDENCIES
TEST_MIRROR

Different semantics on different backends:

TEST_NAME[2]

MySQL:

TEST_CHARSET[3]
TEST_COLLATION

PostgreSQL:

TEST_CHARSET[3]

Oracle:

TEST_USER_CREATE
TEST_USER
TEST_PASSWD
TEST_CREATE
TEST_TBLSPACE
TEST_TBLSPACE_TMP

For the curious-but-lazy, the Oracle settings are needed because Oracle does 
not do "databases" like other backends do, and so the testing framework needs 
a test user and a test tablespace; the TEST_{USER_,}CREATE settigns are 
booleans that control if these will be created for the test or just used. The 
parameters I want to add now, following #21775[1], would specify the exact 
location for the test tablespace files, and their initial and maximum sizes.

Opinions?

Thanks,
Shai.

[1] https://code.djangoproject.com/ticket/21775

[2] On SQLite, the defualt is to use in-memory database (":memory:"), on 
others ('test_' + name); on Oracle the setting is used only for reporting to 
the user, and has no effect on the database used.

[3] The name TEST_CHARSET is common to MySQL and PostgreSQL, but the 
appropriate values are backend-specific.

-- 
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/201401141904.43630.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Improving aggregate support (#14030)

[Josh Smeaton]

I've also written a basic hack (there's no other word for it really) that 
should support the majority of custom aggregates out in the wild. The exact 
commit is here:

https://github.com/jarshwah/django/commit/74c945db2e12444dd012cf89dbf65dddce84ba7b

Basically, it checks to see if add_to_query exists, call it with a known 
alias so that we can then extract the SQLAggregate from query.aggregates, 
and steals the sql_function and sql_template attributes. That said, to 
support the "new" way, the user just needs to copy those two attributes 
onto the models/aggregate, and they now support both the old and new way.

Unfortunately, this doesn't work for GIS. I'll need to port GeoAggregate to 
work like a standard Aggregate, but the work there is extremely minimal. It 
would also gain the support I've built in above for custom Geo Aggregates. 
The "hard" work for GIS is changing the models/query and models/sql/query 
as I've done for core.

Cheers,

- Josh

On Tuesday, 14 January 2014 17:56:29 UTC+11, Josh Smeaton wrote:
>
> Vendor specific SQL is now possible, and uses the monkey patching 
> described above. I worked around the problem of temporarily changing the 
> template, by putting the template and the function into the extra dict on 
> init. Any modifications made to the dict are then made for that instance 
> only. Complicated overrides are possible, giving full control when needed, 
> but calling super after modifying the dicts should be the preferred way of 
> patching.
>
> Relevant code:
>
>
> https://github.com/jarshwah/django/blob/a595a87ea9d90a62ffdf03ced42f1b0904f25e25/django/db/models/expressions.py#L269
>
> https://github.com/jarshwah/django/blob/a595a87ea9d90a62ffdf03ced42f1b0904f25e25/django/db/models/expressions.py#L280
>
> And the tests:
>
>
> https://github.com/jarshwah/django/blob/a595a87ea9d90a62ffdf03ced42f1b0904f25e25/tests/aggregation/tests.py#L800
>
> One of the relevant tests, showing the most simple way of overriding an 
> aggregate:
>
> def lower_case_function_super(self, qn, connection):
> self.extra['sql_function'] = self.extra['sql_function'].lower()
> return super(Sum, self).as_sql(qn, connection)
> setattr(Sum, 'as_%s' % connection.vendor, 
> lower_case_function_super)
>
> Cheers,
>
> - 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/e2f6cd30-63d3-4c50-8b2e-3fa3bff5c0c1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.