Re: python-memcached seems to be unmaintained

2018-10-29 Thread Adam Johnson 
I’ve used pymemcache with Django and even wrote a backend for it that I
never got to open sourcing. I’d be glad of support in core and would help
with code review.

On Mon, 29 Oct 2018 at 00:42, Adrian Turjak  wrote:

> Through some of my last few projects using Django and Memcached I kept
> running into the problem that python-memcached appears to no longer be
> maintained[1], and even before that the release frequency was getting
> quite low.
>
> For Django pylibmc is an alternative, but having to rely on an
> underlying C library is a bit annoying and the library does act a little
> differently.
>
> Give the state of python-memcached I think Django should support
> pymemcache[2]. It is actively maintained by Pintrest, with appropriate
> opensource licensing, is fully python, and appears to be a great library.
>
> There appear to have been attempts by thirdparties to make a Django
> cache backend for it, but none of those are maintained. Bringing the
> support into core, and replacing python-memcached with pymemcache may be
> a better good long term solution than continuing to support and
> recommend an unmaintained library when there is a suitable alternative.
>
> I opened this ticket here to track that, and the recommendation was to
> bring it (rightly so) to the mailing list:
> https://code.djangoproject.com/ticket/29887
>
> I'm also a member of the OpenStack community and I've talked to devs who
> were interested in taking over python-memcached as per the discussion in
> the linked issue, but it looks like OpenStack's oslo.cache is also
> switching to pymemcache at this stage because it offers them a great
> alternative.
>
> Any thoughts?
>
>
> 1: https://github.com/linsomniac/python-memcached/issues/95
> 2: https://github.com/pinterest/pymemcache
>
> --
> 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/3ad5467c-8073-7273-ae5b-00f5dd713efa%40catalyst.net.nz
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Adam

-- 
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/CAMyDDM0WcDuuKFoh4-j2pcbv63EJGUgJnrXzUY%2B4ubpjWarGVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: python-memcached seems to be unmaintained

2018-10-29 Thread Aymeric Augustin 
Hello Adrian,

I think that's a good plan.

If there's opposition to deprecating the python-memcached backend now, it would 
still be possible to introduce and recommend the pymemcache backend.

Best regards,

-- 
Aymeric.



> On 29 Oct 2018, at 01:42, Adrian Turjak  wrote:
> 
> Through some of my last few projects using Django and Memcached I kept
> running into the problem that python-memcached appears to no longer be
> maintained[1], and even before that the release frequency was getting
> quite low.
> 
> For Django pylibmc is an alternative, but having to rely on an
> underlying C library is a bit annoying and the library does act a little
> differently.
> 
> Give the state of python-memcached I think Django should support
> pymemcache[2]. It is actively maintained by Pintrest, with appropriate
> opensource licensing, is fully python, and appears to be a great library.
> 
> There appear to have been attempts by thirdparties to make a Django
> cache backend for it, but none of those are maintained. Bringing the
> support into core, and replacing python-memcached with pymemcache may be
> a better good long term solution than continuing to support and
> recommend an unmaintained library when there is a suitable alternative.
> 
> I opened this ticket here to track that, and the recommendation was to
> bring it (rightly so) to the mailing list:
> https://code.djangoproject.com/ticket/29887
> 
> I'm also a member of the OpenStack community and I've talked to devs who
> were interested in taking over python-memcached as per the discussion in
> the linked issue, but it looks like OpenStack's oslo.cache is also
> switching to pymemcache at this stage because it offers them a great
> alternative.
> 
> Any thoughts?
> 
> 
> 1: https://github.com/linsomniac/python-memcached/issues/95
> 2: https://github.com/pinterest/pymemcache
> 
> -- 
> 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/3ad5467c-8073-7273-ae5b-00f5dd713efa%40catalyst.net.nz.
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3A4436B8-4102-42DE-9905-34F5DD9569F9%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: django migrations on live database for large tables for postgresql

2018-10-29 Thread Aymeric Augustin 
Hello Pavel,

Sorry for the delay in my answer.

Unfortunately I don't know django.db.migrations very well and I won't be able 
to help you with the details of a patch in this area.

I still think improving support for zero downtime migrations would be 
worthwhile. Writing a proposition in a ticket (or, if you're feeling really 
ambition, in a DEP) would be a good way to start.

Sorry I can't help more!

Best regards,

-- 
Aymeric.



> On 7 Oct 2018, at 20:53, pavel.tysla...@gmail.com wrote:
> 
> Hello, Aymeric
> 
> Thanks for your reply.
> 
> CREATE INDEX CONCURRENTLY is a big part for zero downtime migrations support, 
> but there are too many additional questions as should ALTER TABLE ADD COLUMN 
> UNIQUE splitted to CREATE INDEX and constraint creation or should be handled 
> FOREGN KEY, CHECK and NOT NULL constraints creation that can take ACCESS 
> EXCLUSIVE for long time on huge table or is it accessible to avoid 
> transactions in highlighted above cases?
> 
> Unfortunately I don't know what direction django planned to develop, so I can 
> go different ways without support.
> 
> Is it a good idea to create ticket about zero downtime migrations support 
> with detailed proposition of improvements and backward compatibility support?
> 
> Regards, Paveł
> 
> On Sunday, 7 October 2018 10:31:27 UTC+3, Aymeric Augustin wrote:
> Hello Pavel,
> 
> There's an accepted ticket about CREATE INDEX CONCURRENTLY: 
> https://code.djangoproject.com/ticket/21039 
> . A concrete proposal for adding 
> this feature to Django would be interesting.
> 
> I'm not really sure about your two other suggestions. If you think they're 
> improving the PostgreSQL backend, you're welcome to create a ticket and 
> propose a pull request.
> 
> Keep in mind backwards-compatibility if changes are improvements in your use 
> case but perhaps not for everyone else. For example, it may be better that 
> index creating remain an atomic operation (so, not concurrent) by default.
> 
> Best regards,
> 
> -- 
> Aymeric.
> 
> 
> 
>> On 26 Sep 2018, at 07:41, pavel.t...@ <>gmail.com  wrote:
>> 
>> Hi,
>> 
>> I found that django migrations don't designed for live updates on large 
>> tables for postgres, eg. index creation doesn't use concurrently or alter 
>> table operation can take ACCESS EXCLUSIVE lock for long time.
>> 
>> Before I mostly wrote custom migrations, but after one of downtime I decided 
>> to avoid most common cases at all and wrote postgres backend that helps me 
>> in it: https://github.com/tbicr/django-pg-zero-downtime-migrations 
>> . When I wrote 
>> it I found that it's a pretty easy extend core postgres backend, but a few 
>> things required rewrite on my side:
>> 
>> - 
>> https://github.com/django/django/blob/master/django/db/backends/base/schema.py#L152
>>  
>> 
>>  used both for table columns creation and altering table add column, but not 
>> null constraint and index constraints can't be changed without whole method 
>> rewriting
>> - for one core sql statement I found more "safe" equivalent with two sql 
>> statements, but it's a bit hard to execute it, for example more save create 
>> invalid constraint and than validate it or create concurrently index and 
>> than create unique constraint
>> 
>> also I found that not all constraint names quoted in generated sql, for 
>> example add_unique_together got `ALTER TABLE "table_name" ADD CONSTRAINT 
>> table_name_f1_f2_hash_uniq UNIQUE ("f1", "f2")`, but expected `ALTER TABLE 
>> "table_name" ADD CONSTRAINT "table_name_f1_f2_hash_uniq" UNIQUE ("f1", "f2")`
>> 
>> So I just curious is anybody interested to make django migrations more 
>> reliable for large tables in prod or interested in some improvements 
>> highlighted above, that can simplify writing backends for this purpose?
>> 
>> I also will be appreciated if somebody can share another solutions for this 
>> purpose.
>> 
>> Paveł
>> 
>> -- 
>> 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-develop...@ <>googlegroups.com .
>> To post to this group, send email to django-d...@ <>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/421f001b-ca11-42bf-8735-0c6947b41988%40googlegroups.com
>>  
>> .
>> For more options, visit https://group

translate django documentation

2018-10-29 Thread adson . develop 
Hi,

I'm starting to work with Django now and would like to contribute to the 
community, but I have not seen any related contribution topics on 
translating documentation to other languages.

Is there a thread or ticket where I can contribute to that? I would really 
like to start contributing this way because I would gain maturity with the 
framework and learn by translating into my native language (pt-br)

Best 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/00ece068-98a2-4860-b9be-4e5fb7b6261d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.