Renaming the postgresql_psycopg2 backend

[Baptiste Mispelon]

Hi everyone,

After starting a new project recently and failing three times to type
the name of the postgres backend correctly, I was wondering if there's
really any value in keeping around this strange name.

From what I understand, it's a historical artifact from a time when
there was more than one postgres backend.


Could we at least make it an alias of a more simply named "postgresql"
backend?


Thanks,
Baptiste

[Federico Capoano]

I would definitely second this.

[Andriy Sokolovskiy]

Good proposal.
If there will be release of psycopg3, which will work without serious
changes to django codebase, this old name can bring more confusion, so need
to deprecate this.

[Collin Anderson]

We definitely should make sure postgresql_psycopg2 still works as expected. As a data point, Heroku uses "postgres" instead of "postgresql" in their DATABASE_URL scheme. Maybe we could support all three? :)

[Baptiste Mispelon]

I finally got around to creating a ticket for this: https://code.djangoproject.com/ticket/25175

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3ab4f912-fc25-4859-bd8d-5651e2c68e93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

The 'django.db.backends.postgresql' alias was added in Django 1.9 along with import shims in the old location: django.db.backends.postgresql_psycopg2 [0]. I'd like to remove the import shims at some point [1] (but keep the two line shim in django/db/utils.py that allows using DATABASES 'ENGINE': 'django.db.backends.postgresql_psycopg2' indefinitely, given the minimal cost). Do you think subclassing and extending the built-in backend is a common enough use case that it's worth formally deprecating the postgresql_psycopg2 module rather than simply removing it in Django 2.0?

[0] https://github.com/django/django/commit/bcb4fe0012f8f869348ea83f5a35706f4545c44a
[1] https://github.com/django/django/pull/7938

[Adam Johnson]

For reference the lines doing the fixup in django/db/utils.py: https://github.com/django/django/blob/master/django/db/utils.py#L108

I'm fine with simply removing it rather than putting it through the deprecation process - I don't think subclassing database backends is a big enough usecase, given that it's not even documented.

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@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/416e2f39-8c05-4db7-975f-a5dc16380598%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Raffaele Salmaso]

On Mon, Jan 23, 2017 at 8:50 PM, Tim Graham <timog...@gmail.com> wrote:

but keep the two line shim in django/db/utils.py that allows using DATABASES 'ENGINE': 'django.db.backends.postgresql_psycopg2' indefinitely, given the minimal cost

I prefer to remove all references, and have an explicit error on unavailable backend.

--

| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

[Claude Paroz]

Le lundi 23 janvier 2017 20:50:03 UTC+1, Tim Graham a écrit :

(...) Do you think subclassing and extending the built-in backend is a common enough use case that it's worth formally deprecating the postgresql_psycopg2 module rather than simply removing it in Django 2.0?

I am generally strongly against simply dropping non-internal stuff. In those cases, I would be for a short deprecation period (without pending deprecation) so as at least those who follow the good practice of checking their test suite is deprecation-free on Django n before upgrading to Django n + 1 can have a good experience.

Claude

[Josh Smeaton]

I remembered a thing from Michaels talk at #DUTH. Let me present a use case for subclassing a backend:

https://github.com/opbeat/django-postgres-readonly/blob/master/django_postgres_readonly/base.py

I think if we end up favouring immediate deprecation, we could proactively find and inform backend maintainers that would be affected. Their users might not be so appreciative though. I think Claude's position is a good one. A short deprecation period at a minimum.

For my own interest I just did a quick search on PyPI for `django postgres` and found the following (having various levels of django version support):

https://github.com/2degrees/django-postgres-delete-cascade/blob/master/django_postgres_delete_cascade/base.py

https://github.com/kennethreitz/django-postgrespool/blob/master/django_postgrespool/base.py

https://github.com/jdelic/django-postgresql-setrole/blob/master/postgresql_setrole/__init__.py (this one imports from the new location!)

[Adam Johnson]

Ok fair point, I agree it should go through the short deprecation process. It's also very small and not that bothersome to keep around.

--

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+unsubscribe@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/1755d125-ee5e-402f-bbd2-c6edb4c720c6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Tim Graham]

Okay, I updated the PR to use a deprecation. I'd rather not complicate things with an accelerated deprecation.

On Tuesday, January 24, 2017 at 6:39:32 AM UTC-5, Adam Johnson wrote:

Ok fair point, I agree it should go through the short deprecation process. It's also very small and not that bothersome to keep around.

On 24 January 2017 at 10:46, Josh Smeaton <josh.s...@gmail.com> wrote:

I remembered a thing from Michaels talk at #DUTH. Let me present a use case for subclassing a backend:

https://github.com/opbeat/django-postgres-readonly/blob/master/django_postgres_readonly/base.py

I think if we end up favouring immediate deprecation, we could proactively find and inform backend maintainers that would be affected. Their users might not be so appreciative though. I think Claude's position is a good one. A short deprecation period at a minimum.

For my own interest I just did a quick search on PyPI for `django postgres` and found the following (having various levels of django version support):

https://github.com/2degrees/django-postgres-delete-cascade/blob/master/django_postgres_delete_cascade/base.py

https://github.com/kennethreitz/django-postgrespool/blob/master/django_postgrespool/base.py

https://github.com/jdelic/django-postgresql-setrole/blob/master/postgresql_setrole/__init__.py (this one imports from the new location!)

--
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/1755d125-ee5e-402f-bbd2-c6edb4c720c6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Aymeric Augustin]

On 24 Jan 2017, at 19:25, Tim Graham <timog...@gmail.com> wrote:

Okay, I updated the PR to use a deprecation. I'd rather not complicate things with an accelerated deprecation.

+1

I think that’s the right way.

-- 

Aymeric.