Re: Supporting a template database for test db

[Melvyn Sopacua]

On Wednesday 22 March 2017 06:12:49 Tim Graham 
wrote:
> This is already implemented in Django 1.11:
> https://code.djangoproject.com/ticket/27061.

Fantastic, thank you.

-- 
Melvyn Sopacua

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8828249.ZOg9EXAMlh%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Florian Apolloner]

I think there is no need to vendor nowadays, we can just depend on 
whitenoise. (like we do for pytz)

On Wednesday, March 22, 2017 at 5:14:58 PM UTC+1, Aleksej Manaev wrote:
>
> Am I on the right track with the integration of WhiteNoise into Django? 
> Can Someone lead me to the next steps that need to be done?
>
>
> https://github.com/django/django/compare/master...AleksejManaev:ticket_27325?expand=1
>
> I think "django/views/static.py" can't be deprecated because it is used 
> for providing MEDIA_FILES during development and WhiteNoise is only 
> responsible for STATIC_FILES.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d37a3380-e706-40c5-b32d-adc3291f67e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Aleksej Manaev]

Am I on the right track with the integration of WhiteNoise into Django? Can 
Someone lead me to the next steps that need to be done?

https://github.com/django/django/compare/master...AleksejManaev:ticket_27325?expand=1

I think "django/views/static.py" can't be deprecated because it is used for 
providing MEDIA_FILES during development and WhiteNoise is only responsible 
for STATIC_FILES.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/61e59680-a1b9-418c-add2-4a7a79d70bd6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Typing Annotations to django core (PEP 484)

[Tim Graham]

Please search this mailing list's archives for past discussions, e.g. 
https://groups.google.com/d/topic/django-developers/trTEbURFhEY/discussion.

On Wednesday, March 22, 2017 at 8:43:22 AM UTC-4, matthaus woolard wrote:
>
>
> Django 2 will be for python 3.5+ this is the perfect time to start 
> adding Typing Annotations to django core.
>
> There is not need to add to the full code base at once, this is something 
> that could be faced in as new apis are written and added to older apis and 
> sages.
>
> In my view advantages of adding the typing are 3 fold. 
>
> 1) makes the code easier to read
> 2) IDEs (that support this) will be better able to help users, true the 
> existing type info from doc strings is used but the `typing` module 
> provides more control such as generics and typed list/dicts etc
> 3) Once complete Django can use mypy to validate the types across the code 
> base helping with reducing feature bugs through simple to fix typing issues.
>
> Im not sure if there is any large performance hit from using typing on a 
> large project like Django does anyone know of any performance metrics on 
> this?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/68e60e81-08cd-4cc5-a265-f7132c3acfd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Supporting a template database for test db

[Tim Graham]

This is already implemented in Django 1.11: 
https://code.djangoproject.com/ticket/27061.

On Wednesday, March 22, 2017 at 6:53:11 AM UTC-4, Melvyn Sopacua wrote:
>
> Hi,
>
>  
>
> I'm currently running into the problem that in order to run tests, I need 
> to grant my database user super-user privileges.
>
> No problem for dev, but I'd like to avoid that on any system resembling 
> production.
>
>  
>
> This is a Postgresql specific issue, as there is no seperate privilege I 
> can grant that makes it more secure, but even if there was / is going to 
> be, I'd be reluctant to grant it.
>
> I do however want to be able to run tests in staging / production 
> environments.
>
>  
>
> The problem can be avoided by using a template database that already has 
> the required extensions installed. The problem obviously exists for 
> django.contrib.postgres but also for django.contrib.gis and any reusable 
> apps that require an extension (like the custom JSONField implementations 
> out there).
>
>  
>
> I did a coarse search if this was discussed before, but template and 
> database are common words in this group :), so if this has been discussed 
> before, feel free to point me to it.
>
>  
>
> The question being: is there any aversion to supporting TEMPLATE in the 
> DATABASES[TEST] setting and that the database will then be created using 
> the template database (so mapping to CREATE DATABASE ... TEMPLATE ..)?
>
> -- 
>
> Melvyn Sopacua
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/38c11fbb-81b5-49d8-8c9c-3360d02d335e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Typing Annotations to django core (PEP 484)

[Florian Apolloner]

Hi,

On Wednesday, March 22, 2017 at 1:43:22 PM UTC+1, matthaus woolard wrote:
>
> 1) makes the code easier to read
>

I disagree, they imo make the code harder to read, especially when the 
annotations are becoming a bit more complex.
 

> Im not sure if there is any large performance hit from using typing on a 
> large project like Django does anyone know of any performance metrics on 
> this?
>

No, but if we use stub files for the annotations this should not be of any 
concern.

Cheers,
Florian 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bfce7a45-60d3-4012-98fe-d4a005880deb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Typing Annotations to django core (PEP 484)

[matthaus woolard]

Django 2 will be for python 3.5+ this is the perfect time to start 
adding Typing Annotations to django core.

There is not need to add to the full code base at once, this is something 
that could be faced in as new apis are written and added to older apis and 
sages.

In my view advantages of adding the typing are 3 fold. 

1) makes the code easier to read
2) IDEs (that support this) will be better able to help users, true the 
existing type info from doc strings is used but the `typing` module 
provides more control such as generics and typed list/dicts etc
3) Once complete Django can use mypy to validate the types across the code 
base helping with reducing feature bugs through simple to fix typing issues.

Im not sure if there is any large performance hit from using typing on a 
large project like Django does anyone know of any performance metrics on 
this?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8f4c70a4-8e40-400d-9011-d7d50e9b2174%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Supporting a template database for test db

[Florian Apolloner]

Sounds sensible to me.

On Wednesday, March 22, 2017 at 11:53:11 AM UTC+1, Melvyn Sopacua wrote:
>
> Hi,
>
>  
>
> I'm currently running into the problem that in order to run tests, I need 
> to grant my database user super-user privileges.
>
> No problem for dev, but I'd like to avoid that on any system resembling 
> production.
>
>  
>
> This is a Postgresql specific issue, as there is no seperate privilege I 
> can grant that makes it more secure, but even if there was / is going to 
> be, I'd be reluctant to grant it.
>
> I do however want to be able to run tests in staging / production 
> environments.
>
>  
>
> The problem can be avoided by using a template database that already has 
> the required extensions installed. The problem obviously exists for 
> django.contrib.postgres but also for django.contrib.gis and any reusable 
> apps that require an extension (like the custom JSONField implementations 
> out there).
>
>  
>
> I did a coarse search if this was discussed before, but template and 
> database are common words in this group :), so if this has been discussed 
> before, feel free to point me to it.
>
>  
>
> The question being: is there any aversion to supporting TEMPLATE in the 
> DATABASES[TEST] setting and that the database will then be created using 
> the template database (so mapping to CREATE DATABASE ... TEMPLATE ..)?
>
> -- 
>
> Melvyn Sopacua
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/738ec92a-0373-4931-b6e4-923d47faa7ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Supporting a template database for test db

[Melvyn Sopacua]

Hi,

I'm currently running into the problem that in order to run tests, I need to 
grant my 
database user super-user privileges.
No problem for dev, but I'd like to avoid that on any system resembling 
production.

This is a Postgresql specific issue, as there is no seperate privilege I can 
grant that 
makes it more secure, but even if there was / is going to be, I'd be reluctant 
to grant 
it.
I do however want to be able to run tests in staging / production environments.

The problem can be avoided by using a template database that already has the 
required extensions installed. The problem obviously exists for 
django.contrib.postgres but also for django.contrib.gis and any reusable apps 
that 
require an extension (like the custom JSONField implementations out there).

I did a coarse search if this was discussed before, but template and database 
are 
common words in this group :), so if this has been discussed before, feel free 
to point 
me to it.

The question being: is there any aversion to supporting TEMPLATE in the 
DATABASES[TEST] setting and that the database will then be created using the 
template database (so mapping to CREATE DATABASE ... TEMPLATE ..)?
-- 
Melvyn Sopacua

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1771797.SbPkkOfdAJ%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM query syntax enhancement

[Asif Saifuddin]

Hi Aric,

I checked your package. it's nice too. thanks for the work.

Asif

On Monday, October 17, 2016 at 4:38:26 AM UTC+6, Aric Coady wrote:
>
> +1.  I implemented much the same thing for part of django-model-values 
> , but went with F 
> expressions  
> as the basis instead.  Primarily because F expressions already support 
> operator overloading and are a natural intermediate object;  from there one 
> can create Q, OrderBy, and Func objects.
>
> In []: from model_values import F
>
> In []: F.user.created
> Out[]: FExpr(user__created)
>
> In []: F.user.created >= 0
> Out[]: 
>
> In []: F.user.created.min()
> Out[]: Min(FExpr(user__created))
>
> In []: -F.user.created
> Out[]: OrderBy(FExpr(user__created), descending=True)
>
> In []: F.text.iexact('...')
> Out[]: 
>
>
>
>
> On Thursday, October 6, 2016 at 10:04:56 AM UTC-7, Alexey Zankevich wrote:
>>
>> Hey all,
>>
>> Just want to announce recent changes in Django ORM Sugar library, which 
>> might be useful in future Django query syntax enhancement (if ever happens).
>> 1. Now it supports indexes and slices:
>>
>> >>> Q.data.owner.other_pets[0].name='Fishy'
>> Q(data__owner__other_pets__0__name='Fishy')
>> >>> Q.tags[0] == 'thoughts'
>> Q(tags__0='thoughts')
>> >>> Q.tags[0:2].contains(['thoughts']) 
>> Q(tags__0_2__contains=['thoughts'])
>>
>>
>> 2. Previously, it was only possible to call defined method (like it is 
>> done for *is_not_null()* function) or registered with decorator. Now if 
>> you try to call unknown function of sugar Q, it will internally pass 
>> function name and append it as *__functionname *to lookup field:
>>
>> >>> Q.user.username.contains('Rodriguez')
>> Q(user__username__contains='Rodriguez')
>>
>>
>> There is no such function "contains" anymore in sugar Q, however, it just 
>> adds *__contains* to lookup field and passes parameter to it.
>>
>> 3. It will pass a tuple to lookup if multiple arguments passed:
>>
>> >>> Q.user.create_datetime.range(d1, d2)
>> Q(user__create_datetime__range=(d1, d2))
>>
>>
>> I think the library is at the final state now and isn't going to get new 
>> substantial features, but responses are highly appreciated.
>>
>> Regards,
>> Alexey
>>
>>
>> On Sunday, August 16, 2015 at 4:18:26 PM UTC+3, Alexey Zankevich wrote:
>>>
>>> Hi all,
>>>
>>> This topic is related to the current ORM query syntax with underscores.
>>> There are lots of arguing related to it, anyway it has pros and cons.
>>>
>>> Let's take a concrete example of querying a model:
>>>
>>> >>> 
>>> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday)
>>>
>>>
>>> Pros:
>>>
>>> 1. The syntax is easy to understand
>>> 2. Can be extended with custom transforms and lookups
>>>
>>> However, there are several cons:
>>>
>>> 1. Long strings is hard to read, especially if we have fields with 
>>> underscores.
>>> It's really easy to make a mistake by missing one:
>>>
>>> >>> 
>>> GameSession.objects.filter(user_profile__last_login_date__gte=yesterday)
>>>
>>> Not easy to catch missing underscore between user and profile, is it? 
>>> Even
>>> though, it's not easy to say whether it should be "user_profile" 
>>> attribute or
>>> user.profile foreign key.
>>>
>>> 2. Query strings can't be reused, thus the approach violates DRY 
>>> principle.
>>> For example, we need to order results by last_login_date:
>>>
>>> >>> 
>>> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday) \
>>> .order_by('user__profile__last_login_date')
>>>
>>> We can't keep user__profile_login_date as a variable as in the first 
>>> part of the
>>> expression we use a keyword argument, meanwhile in the second part - 
>>> just a 
>>> string. And thus we just have to type query path twice.
>>>
>>> 3. Lookup names not natural to Python language and require to be 
>>> remembered or
>>> looked up in documentation. For example, "__gte" or "__lte" lookups tend 
>>> to be
>>> confused with "ge" and "le" due to similarity to methods "__ge__" and 
>>> "__le__".
>>>
>>> 4. Lookup keywords limited to a single argument only, very inconvenient 
>>> when
>>> necessary to filter objects by range.
>>>
>>> I was thinking a lot trying to solve those issues, keeping in mind Django
>>> approaches. Finally I came up with solution to extend Q objects with dot
>>> expression syntax:
>>>
>>> >>> GameSession.objecs.filter(Q.user.profile.last_login_date >= 
>>> yesterday)
>>>
>>> Q is a factory instance for old-style Q objects. Accessing attribute by 
>>> dot
>>> returns a child factory, calling factory will instantiate old-style Q 
>>> object.
>>>
>>> >>> Q
>>> 
>>>
>>> >>> Q.user.profile
>>> 
>>>
>>> >>> Q(user__name='Bob')
>>> 
>>>
>>> It overrides operators, so comparing factory with value returns a 
>>> related Q
>>> object:
>>>
>>> >>> Q.user.name == 'Bob'
>>> 
>>>
>>> Factory has several helper functions for lookups which aren't related to 
>>>