Re: Case-insensitive email as username

[Aymeric Augustin]

2015-11-23 23:52 GMT+01:00 Carl Meyer :

I've implemented the CITEXT-based solution a couple times; I think for a
> PostgreSQL-based project it's the preferable option overall.
>

Perhaps we should add native support in contrib.postgres?

I'm forseeing a small difficulty in terms of API. This is a behavior I'd
like
to "mix in" to some fields but I can't say if that will be easy to
implement.

The general ideas would be:

# A mixin

class CITextField(TextField):
# ...

# Case-insensitive versions of some built-in Django default fields
# (if we consider that makes sense)

class CIEmailField(CITextField, EmailField):
pass

# The possibility for users to make custom fields case insensitive

class CITagField(CITextField, TagField):
pass

-- 
Aymeric.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mW60wZcJ-6ahReqNAf4rDN%2BV5dQ%3Dahn%3Dh3Oz3X4uz81pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Non-atomic migrations in Django?

[Ludwig Hähne]

Hi all,

I'd like to get your feedback on supporting non-atomic migrations in Django.

Database transactions are always wrapped in transactions (on DBs that 
support transactional DDL like Postgres). Generally this is a good idea. 

However, one can't do batched updates in data migrations which is essential 
for performing changes on big tables on a live DB [1]. It's also not 
possible to create indexes concurrently on Postgres from inside a 
transaction.

Therefore, I'd like to have support for non-atomic migrations in Django 
because it's pretty messy to work around not having proper support for that 
[2].

Here's a proof-of-concept implementation [3] of exempting specific 
migrations from being wrapped in a transaction by setting `atomic = False` 
on the migration:

https://github.com/django/django/compare/master...Ableton:non-atomic-migrations

Do you agree that non-atomic migrations should be supported by Django?

Is setting an `atomic` property on a migration a good API for that?

If there's a chance this will be merged, I'd add documentation, incorporate 
your feedback, and open a ticket or PR.

Thanks,
Ludwig

[1] http://pankrat.github.io/2015/django-migrations-without-downtimes/
[2] 
http://stackoverflow.com/questions/31247810/commit-manually-in-django-data-migration
[3] 
https://github.com/django/django/compare/master...Ableton:non-atomic-migrations

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c062736d-2ebc-42cd-83a5-fe4d064cb24e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Non-atomic migrations in Django?

[Anssi Kääriäinen]

I don't see any problem with optional non-transactional migrations. So, +1
for the idea and API. I haven't looked at the implementation, so no
comments about that.

 - Anssi

On Tuesday, November 24, 2015, Ludwig Hähne  wrote:

> Hi all,
>
> I'd like to get your feedback on supporting non-atomic migrations in
> Django.
>
> Database transactions are always wrapped in transactions (on DBs that
> support transactional DDL like Postgres). Generally this is a good idea.
>
> However, one can't do batched updates in data migrations which is
> essential for performing changes on big tables on a live DB [1]. It's also
> not possible to create indexes concurrently on Postgres from inside a
> transaction.
>
> Therefore, I'd like to have support for non-atomic migrations in Django
> because it's pretty messy to work around not having proper support for that
> [2].
>
> Here's a proof-of-concept implementation [3] of exempting specific
> migrations from being wrapped in a transaction by setting `atomic = False`
> on the migration:
>
>
> https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>
> Do you agree that non-atomic migrations should be supported by Django?
>
> Is setting an `atomic` property on a migration a good API for that?
>
> If there's a chance this will be merged, I'd add documentation,
> incorporate your feedback, and open a ticket or PR.
>
> Thanks,
> Ludwig
>
> [1] http://pankrat.github.io/2015/django-migrations-without-downtimes/
> [2]
> http://stackoverflow.com/questions/31247810/commit-manually-in-django-data-migration
> [3]
> https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c062736d-2ebc-42cd-83a5-fe4d064cb24e%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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALMtK1GDj0_wheW5dHEdp1ZLYcXa-6OpxfHgcnHqWtMcT9YG0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Non-atomic migrations in Django?

[Aymeric Augustin]

I like the API as well. Surprisingly, I couldn't find a Trac ticket about
this.

-- 
Aymeric.

2015-11-24 16:39 GMT+01:00 Anssi Kääriäinen :

> I don't see any problem with optional non-transactional migrations. So, +1
> for the idea and API. I haven't looked at the implementation, so no
> comments about that.
>
>  - Anssi
>
>
> On Tuesday, November 24, 2015, Ludwig Hähne  wrote:
>
>> Hi all,
>>
>> I'd like to get your feedback on supporting non-atomic migrations in
>> Django.
>>
>> Database transactions are always wrapped in transactions (on DBs that
>> support transactional DDL like Postgres). Generally this is a good idea.
>>
>> However, one can't do batched updates in data migrations which is
>> essential for performing changes on big tables on a live DB [1]. It's also
>> not possible to create indexes concurrently on Postgres from inside a
>> transaction.
>>
>> Therefore, I'd like to have support for non-atomic migrations in Django
>> because it's pretty messy to work around not having proper support for that
>> [2].
>>
>> Here's a proof-of-concept implementation [3] of exempting specific
>> migrations from being wrapped in a transaction by setting `atomic = False`
>> on the migration:
>>
>>
>> https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>>
>> Do you agree that non-atomic migrations should be supported by Django?
>>
>> Is setting an `atomic` property on a migration a good API for that?
>>
>> If there's a chance this will be merged, I'd add documentation,
>> incorporate your feedback, and open a ticket or PR.
>>
>> Thanks,
>> Ludwig
>>
>> [1] http://pankrat.github.io/2015/django-migrations-without-downtimes/
>> [2]
>> http://stackoverflow.com/questions/31247810/commit-manually-in-django-data-migration
>> [3]
>> https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/c062736d-2ebc-42cd-83a5-fe4d064cb24e%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 (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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALMtK1GDj0_wheW5dHEdp1ZLYcXa-6OpxfHgcnHqWtMcT9YG0g%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aymeric.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mUiytuj26np%3DzP-kX4fHmPv3i0u7Hn-a8GTGuHk4sF3qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Non-atomic migrations in Django?

[Marc Tamlyn]

+1 to idea and API. I've wished I had this recently - even if it's just so
I can check up on the progress of a slow running data generation migration
so it flushes the data every few 100 records.

On 24 November 2015 at 16:07, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> I like the API as well. Surprisingly, I couldn't find a Trac ticket about
> this.
>
> --
> Aymeric.
>
> 2015-11-24 16:39 GMT+01:00 Anssi Kääriäinen :
>
>> I don't see any problem with optional non-transactional migrations. So,
>> +1 for the idea and API. I haven't looked at the implementation, so no
>> comments about that.
>>
>>  - Anssi
>>
>>
>> On Tuesday, November 24, 2015, Ludwig Hähne  wrote:
>>
>>> Hi all,
>>>
>>> I'd like to get your feedback on supporting non-atomic migrations in
>>> Django.
>>>
>>> Database transactions are always wrapped in transactions (on DBs that
>>> support transactional DDL like Postgres). Generally this is a good idea.
>>>
>>> However, one can't do batched updates in data migrations which is
>>> essential for performing changes on big tables on a live DB [1]. It's also
>>> not possible to create indexes concurrently on Postgres from inside a
>>> transaction.
>>>
>>> Therefore, I'd like to have support for non-atomic migrations in Django
>>> because it's pretty messy to work around not having proper support for that
>>> [2].
>>>
>>> Here's a proof-of-concept implementation [3] of exempting specific
>>> migrations from being wrapped in a transaction by setting `atomic = False`
>>> on the migration:
>>>
>>>
>>> https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>>>
>>> Do you agree that non-atomic migrations should be supported by Django?
>>>
>>> Is setting an `atomic` property on a migration a good API for that?
>>>
>>> If there's a chance this will be merged, I'd add documentation,
>>> incorporate your feedback, and open a ticket or PR.
>>>
>>> Thanks,
>>> Ludwig
>>>
>>> [1] http://pankrat.github.io/2015/django-migrations-without-downtimes/
>>> [2]
>>> http://stackoverflow.com/questions/31247810/commit-manually-in-django-data-migration
>>> [3]
>>> https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>>>
>>> --
>>> 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 http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/c062736d-2ebc-42cd-83a5-fe4d064cb24e%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 (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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CALMtK1GDj0_wheW5dHEdp1ZLYcXa-6OpxfHgcnHqWtMcT9YG0g%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Aymeric.
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANE-7mUiytuj26np%3DzP-kX4fHmPv3i0u7Hn-a8GTGuHk4sF3qw%40mail.gmail.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  (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 

Re: Case-insensitive email as username

[Chris Foresman]

We usually just handle this with a custom serializer (or form) field that 
converts all input to lowercase. That way we don't have to change any 
lookups or anything; all emails that come in to the system are already 
lowercase. Of course, that doesn't preserve what users enter but IME 
anything uppercase is just a fault of using the wrong text box on iOS or 
Android.



On Tuesday, November 24, 2015 at 5:33:54 AM UTC-6, Aymeric Augustin wrote:
>
> 2015-11-23 23:52 GMT+01:00 Carl Meyer >:
>
> I've implemented the CITEXT-based solution a couple times; I think for a
>> PostgreSQL-based project it's the preferable option overall.
>>
>
> Perhaps we should add native support in contrib.postgres?
>
> I'm forseeing a small difficulty in terms of API. This is a behavior I'd 
> like
> to "mix in" to some fields but I can't say if that will be easy to 
> implement.
>
> The general ideas would be:
>
> # A mixin
>
> class CITextField(TextField):
> # ...
>
> # Case-insensitive versions of some built-in Django default fields
> # (if we consider that makes sense)
>
> class CIEmailField(CITextField, EmailField):
> pass
>
> # The possibility for users to make custom fields case insensitive
>
> class CITagField(CITextField, TagField):
> pass
>
> -- 
> Aymeric.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/72d064df-7599-4111-994a-d338dc81e7a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANNOUNCE] Django security releases issued (1.7.11, 1.8.7, and 1.9rc2)

[Tim Graham]

Today the Django team issued multiple releases -- Django 1.7.11, 1.8.7, and 
1.9rc2 -- as part of our security process. These releases address a 
security issue, and we encourage all users to upgrade as soon as possible.

More details can be found on our blog:

https://www.djangoproject.com/weblog/2015/nov/24/security-releases-issued/

As a reminder, we ask that potential security issues be reported via 
private email to secur...@djangoproject.com and not via Django's Trac 
instance or the django-developers list. Please see 
https://www.djangoproject.com/security for further information.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9fb0c4f7-6f07-4fa9-b5d9-15137d077b08%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Bringing some popular must have django tools/packages under django org umbrella

[Asif Saifuddin]

How is the idea? tools like django-debug-toolbar, django-silk, 
django-taggit, django-filter etc and some more de facto tools under the 
umbrella of django github org?

Regards

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2492490d-0bd5-4424-9bae-95471be34664%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bringing some popular must have django tools/packages under django org umbrella

[Collin Anderson]

Hi,

Say a little bit more: What would be the goal? What would you hope would be 
accomplished by doing this?

Thanks,
Collin

On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin wrote:
>
> How is the idea? tools like django-debug-toolbar, django-silk, 
> django-taggit, django-filter etc and some more de facto tools under the 
> umbrella of django github org?
>
> Regards
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/70062405-3ccd-49b2-9118-ec1679203cd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Non-atomic migrations in Django?

[Andrew Godwin]

I also agree this looks sensible - I think South even had an attribute like
this on the migration class, it just never got ported over. +1

On Tue, Nov 24, 2015 at 8:19 AM, Marc Tamlyn  wrote:

> +1 to idea and API. I've wished I had this recently - even if it's just so
> I can check up on the progress of a slow running data generation migration
> so it flushes the data every few 100 records.
>
> On 24 November 2015 at 16:07, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> I like the API as well. Surprisingly, I couldn't find a Trac ticket about
>> this.
>>
>> --
>> Aymeric.
>>
>> 2015-11-24 16:39 GMT+01:00 Anssi Kääriäinen :
>>
>>> I don't see any problem with optional non-transactional migrations. So,
>>> +1 for the idea and API. I haven't looked at the implementation, so no
>>> comments about that.
>>>
>>>  - Anssi
>>>
>>>
>>> On Tuesday, November 24, 2015, Ludwig Hähne  wrote:
>>>
 Hi all,

 I'd like to get your feedback on supporting non-atomic migrations in
 Django.

 Database transactions are always wrapped in transactions (on DBs that
 support transactional DDL like Postgres). Generally this is a good idea.

 However, one can't do batched updates in data migrations which is
 essential for performing changes on big tables on a live DB [1]. It's also
 not possible to create indexes concurrently on Postgres from inside a
 transaction.

 Therefore, I'd like to have support for non-atomic migrations in Django
 because it's pretty messy to work around not having proper support for that
 [2].

 Here's a proof-of-concept implementation [3] of exempting specific
 migrations from being wrapped in a transaction by setting `atomic = False`
 on the migration:


 https://github.com/django/django/compare/master...Ableton:non-atomic-migrations

 Do you agree that non-atomic migrations should be supported by Django?

 Is setting an `atomic` property on a migration a good API for that?

 If there's a chance this will be merged, I'd add documentation,
 incorporate your feedback, and open a ticket or PR.

 Thanks,
 Ludwig

 [1] http://pankrat.github.io/2015/django-migrations-without-downtimes/
 [2]
 http://stackoverflow.com/questions/31247810/commit-manually-in-django-data-migration
 [3]
 https://github.com/django/django/compare/master...Ableton:non-atomic-migrations

 --
 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 http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/c062736d-2ebc-42cd-83a5-fe4d064cb24e%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 (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 http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CALMtK1GDj0_wheW5dHEdp1ZLYcXa-6OpxfHgcnHqWtMcT9YG0g%40mail.gmail.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Aymeric.
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CANE-7mUiytuj26np%3DzP-kX4fHmPv3i0u7Hn-a8GTGuHk4sF3qw%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit http

Re: Bringing some popular must have django tools/packages under django org umbrella

[Asif Saifuddin]

The projects will have the official tool status + the maintainer of the
projects will be able to collaborate better with django core team? less
risk of being abandoned by the maintainers etc.

IMHO

On Wed, Nov 25, 2015 at 12:31 AM, Collin Anderson 
wrote:

> Hi,
>
> Say a little bit more: What would be the goal? What would you hope would
> be accomplished by doing this?
>
> Thanks,
> Collin
>
> On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin wrote:
>>
>> How is the idea? tools like django-debug-toolbar, django-silk,
>> django-taggit, django-filter etc and some more de facto tools under the
>> umbrella of django github org?
>>
>> Regards
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/bIzfHebE2sw/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/70062405-3ccd-49b2-9118-ec1679203cd1%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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKAqTgrnMoqy-%3DdDUx31Dgru6XTzT3e-T%3DhspY-CDK5tV9k1gQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bringing some popular must have django tools/packages under django org umbrella

[Marc Tamlyn]

This is something the core team discussed in Amsterdam. I believe there was
consensus to trial it with Django registration. I should catch up with
James and see if it is transferred. If this goes well I see no reason why
not.

The biggest problem is the selection of packages, we have historically
wanted to avoid too much bikeshedding. Initially it's likely to be mostly
relatively inactive small utilities I think. But I think we are open to
being more risky here.

M
On 24 Nov 2015 7:02 pm, "Asif Saifuddin"  wrote:

> The projects will have the official tool status + the maintainer of the
> projects will be able to collaborate better with django core team? less
> risk of being abandoned by the maintainers etc.
>
> IMHO
>
> On Wed, Nov 25, 2015 at 12:31 AM, Collin Anderson 
> wrote:
>
>> Hi,
>>
>> Say a little bit more: What would be the goal? What would you hope would
>> be accomplished by doing this?
>>
>> Thanks,
>> Collin
>>
>> On Tuesday, November 24, 2015 at 1:27:11 PM UTC-5, Asif Saifuddin wrote:
>>>
>>> How is the idea? tools like django-debug-toolbar, django-silk,
>>> django-taggit, django-filter etc and some more de facto tools under the
>>> umbrella of django github org?
>>>
>>> Regards
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/bIzfHebE2sw/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/70062405-3ccd-49b2-9118-ec1679203cd1%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 (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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAKAqTgrnMoqy-%3DdDUx31Dgru6XTzT3e-T%3DhspY-CDK5tV9k1gQ%40mail.gmail.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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FzQ8cCgF7pR%2BRtPiSkNc5W4ipeWfwLz0hi4q_xzxZoAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Make template caching a feature of the Django template engine

[Marc Tamlyn]

So. If I understand correctly, this would deprecate the existing cached
template loader, replace it with a more powerful, debug ready version (on
by default?). Assuming this is what you mean, I wholeheartedly support
this. There's no reason not to be performant by default.

Marc
On 23 Nov 2015 2:16 pm, "Jaap Roes"  wrote:

> It’s considered a good practice to enable template caching in Django. It
> saves on the overhead of loading and parsing templates and turning them
> into template objects, which can give a nice performance boost when
> repeatedly rendering the same templates.
>
> Currently it’s possible to enable template caching by using the cached
> loader. To do so you’ll need to add the loaders option to the engine
> settings and set it to a nesting of lists/tuples (I’ll wager no one can get
> this correct on the first try without first consulting the docs). This
> makes enabling template caching needlessly hard, and the discoverability of
> this feature lower than necessary. To this day I run into developers who
> have worked with Django for years but are unaware of the cached loader.
>
> One of the downsides of enabling the cached loader is that it will cache
> templates until the server is reloaded. This makes it ill suited for
> development. I have, on many occasions, seen developers (including myself)
> forget to turn off template caching in their local settings, resulting in
> lost time trying to figure out why their changes are not showing.
>
> I think Django can, and should do better. The bare minimum is to make
> template caching a simple toggle option that can be passed to the engine (
> https://code.djangoproject.com/ticket/25788 /
> https://github.com/jaap3/django/commit/21e9d3aa0eb0a9d2728f8a35318d49d528f3a60f
> (an admittedly naive patch)). This way cache_templates could simply mirror
> DEBUG and (new) projects can have a sane template caching configuration by
> default.
>
> It would also be useful to have caching enabled in development so the
> template loading behaviour is (mostly) the same in development as it is in
> production.
>
> One reason for this is that custom template tags need to be thread safe (
> https://docs.djangoproject.com/en/1.8/howto/custom-template-tags/#thread-safety-considerations).
> Because cached templates always reuse the nodes it’s easier to notice when
> a template tag misbehaves.
>
> Another reason is that the performance of template rendering will be
> roughly the same development as in production, which can make a great
> difference if you’re working with complex templates and/or custom tags that
> perform expensive operations in their __init__.
>
> Off course, having caching on in development is impractical if templates
> stay cached forever. So some sort of template invalidation and reloading
> system needs to be added. It’s actually fairly easy to add this to the
> cached loader https://code.djangoproject.com/ticket/25791 /
> https://github.com/jaap3/django/commit/20e1caa9f923d82ce60dff155304de5289242186
> (an earlier/alternative implementation that moves caching to the engine can
> be found here:
> https://github.com/prestontimmons/django/commit/4683300c60033ba0db472c81244f01ff932c6fb3
> ).
>
> With caching and auto reloading as a core feature of Django’s engine it
> will be (somewhat) on par with the alternative Jinja2 engine shipped by
> Django. Jinja2’s Engine lets you configure an Environment (
> http://jinja.pocoo.org/docs/dev/api/#jinja2.Environment) using the
> engine's options. This includes setting a bytecode_cache and enabling
> auto_reload (this last option mirrors DEBUG by default in Django).
>
> So in short, I propose making template caching a true feature of Django’s
> template engine. Which can be configured in a way similarl to the Jinja2
> engine (and could be on by default for new projects):
>
> TEMPLATES = [{
> 'BACKEND': 'django.template.backends.django.DjangoTemplates',
> 'DIRS': [os.path.join(BASE_DIR, 'templates')],
> 'APP_DIRS': True
> 'OPTIONS': {
> 'cache_templates': True,
> 'auto_reload': DEBUG  // this could be the default set by the
> engine
> }
> }]
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c2897e2b-c506-44e3-93e4-cb077bb8f4ac%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscrib

Re: Case-insensitive email as username

[Carl Meyer]

On 11/24/2015 04:33 AM, Aymeric Augustin wrote:
> 2015-11-23 23:52 GMT+01:00 Carl Meyer  >:
> 
> I've implemented the CITEXT-based solution a couple times; I think for a
> PostgreSQL-based project it's the preferable option overall.
> 
> Perhaps we should add native support in contrib.postgres?

I'm in favor. I think it's likely as common a need (if not more common)
as the other utilities provided there -- even if most people who need it
are currently probably using an ORM-level or form-level instead of
db-level solution.

> I'm forseeing a small difficulty in terms of API. This is a behavior I'd
> like
> to "mix in" to some fields but I can't say if that will be easy to
> implement.
> 
> The general ideas would be:
> 
> # A mixin
> 
> class CITextField(TextField):
> # ...
> 
> # Case-insensitive versions of some built-in Django default fields
> # (if we consider that makes sense)
> 
> class CIEmailField(CITextField, EmailField):
> pass
> 
> # The possibility for users to make custom fields case insensitive
> 
> class CITagField(CITextField, TagField):
> pass

Here's the entire implementation of my CiEmailField:

class CiEmailField(models.EmailField):
"""An EmailField that uses the CITEXT Postgres column type."""
def db_type(self, connection):
return 'CITEXT'

So I think that's quite amenable to a mixin implementation.

Carl

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5654BEA9.3080503%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Non-atomic migrations in Django?

[Markus Holtermann]

Hi Ludwig,

the API looks clean and sensible to me. +1 for getting that into 1.10

/Markus

On November 25, 2015 12:00:59 AM GMT+10:00, "Ludwig Hähne"  
wrote:
>Hi all,
>
>I'd like to get your feedback on supporting non-atomic migrations in
>Django.
>
>Database transactions are always wrapped in transactions (on DBs that 
>support transactional DDL like Postgres). Generally this is a good
>idea. 
>
>However, one can't do batched updates in data migrations which is
>essential 
>for performing changes on big tables on a live DB [1]. It's also not 
>possible to create indexes concurrently on Postgres from inside a 
>transaction.
>
>Therefore, I'd like to have support for non-atomic migrations in Django
>
>because it's pretty messy to work around not having proper support for
>that 
>[2].
>
>Here's a proof-of-concept implementation [3] of exempting specific 
>migrations from being wrapped in a transaction by setting `atomic =
>False` 
>on the migration:
>
>https://github.com/django/django/compare/master...Ableton:non-atomic-migrations
>
>Do you agree that non-atomic migrations should be supported by Django?
>
>Is setting an `atomic` property on a migration a good API for that?
>
>If there's a chance this will be merged, I'd add documentation,
>incorporate 
>your feedback, and open a ticket or PR.
>
>Thanks,
>Ludwig
>
>[1] http://pankrat.github.io/2015/django-migrations-without-downtimes/
>[2] 
>http://stackoverflow.com/questions/31247810/commit-manually-in-django-data-migration
>[3] 
>https://github.com/django/django/compare/master...Ableton:non-atomic-migrations

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/704E30F0-A249-45CD-B084-FCECCF711E88%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: Python 3.5 Support in Django 1.8.x?

[James Bennett]

Bumping this thread a bit because I subscribe to Debian's tracker for their
Django package, and there's some question of whether we do or do not
officially support Python 3.5 on Django 1.8. Was there ever a final
decision?

On Tue, Oct 27, 2015 at 5:19 PM, Ned Batchelder 
wrote:

> BTW, there's a move afoot to reconsider removing inspect.getargspec:
> http://bugs.python.org/issue20438 and http://bugs.python.org/issue25486
>
> --Ned.
>
>
> On 10/24/15 10:30 AM, Tim Graham wrote:
>
> Here's the PR to remove 50K lines of deprecation warnings when running the
> Django 1.8 tests on Python 3.5 as well as to fix the two test failures
> caused by those warnings: 
> https://github.com/django/django/pull/5472
>
> In case you look and wonder about the build failures, Jenkins broke today
> after a new release of sqlparse. I submitted a fix:
> https://github.com/andialbrecht/sqlparse/pull/203
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/django-developers/f13c34f1-d059-4017-8626-41d6d5c3a760%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 (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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/563014A1.7000309%40nedbatchelder.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  (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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8YvtqrTa7OTTQR-nbFqaanV0jc38XLHJXWMq6VuCLbYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python 3.5 Support in Django 1.8.x?

[James Bennett]

Never mind, just saw that 3.5 is listed in the 1.8 release notes and
answered my own question.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9rmp3jA0DhdKRE95HRmJYLC1%3DaoYcxX9Y_rY7TgDj8EQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #25582: Add a way to build URLs with query strings

[Rob Hudson]

At Mozilla we've used a jinja2 template filter called 'urlparams' for quite
some time. You can see the code in jingo here:
https://github.com/jbalogh/jingo/blob/master/jingo/helpers.py#L116

In Python:
urlparams(reverse('translate', kwargs={'slug': document.slug}),
to_locale=locale)

In Jinja2 templates (but the idea would be similar in Django):
https://code.djangoproject.com/ticket/25582
>>
>>  {{{
>>
>> It is a common question on stackoverflow and other places:
>>
>> How to reverse() to url including GET parameters? Example:
>> .../myview?foo=bar
>>
>> ​
>> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>>
>> ​http://stackoverflow.com/a/27641445/633961
>>
>> It would be very nice if django could implement a short-cut which provides
>> this.
>> It would be useful for python code and template, too.
>> }}}
>>
>> {{{
>> If we do add it, it likely needs a discussion on the
>> DevelopersMailingList
>>  to figure
>> out what the API should look like. See also #10941
>>  which asks for a template
>> tag for creating query strings in templates.
>> }}}
>>
>> What do you think?
>>
>>
>>
>> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0f8dbd9f-b42d-4d17-806b-d965c0999b85%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-Rob

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAK2QP5bwU3s_1uzGMiwmu%2BP_u7SP5eF0zq3-E8k1sUj-TD2E7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.