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 t
I would definitely second this.
On Wednesday, July 15, 2015 at 3:17:30 PM UTC+2, Baptiste Mispelon wrote:
>
> 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 ke
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.
On 7/15/15 15:17, Baptiste Mispelon wrote:
> Hi everyone,
>
> After starting a new project recently and failing three
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? :)
On Wednesday, July 15, 2015 at 9:17:30 AM UTC-4, Baptiste Mispelon wrote:
>
> Hi everyone
I finally got around to creating a ticket for this:
https://code.djangoproject.com/ticket/25175
On 07/15/2015 03:30 PM, Collin Anderson wrote:
We definitely should make sure postgresql_psycopg2 still works as
expected. As a data point, Heroku uses "postgres" instead of
"postgresql" in their DA
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'
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 t
On Mon, Jan 23, 2017 at 8:50 PM, Tim Graham 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
unavaila
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 s
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 backe
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 wrote:
> I remembered a thing from Michaels talk at #DUTH. Let me present a use
> case for subclassing a backend:
>
>
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
> On 24 Jan 2017, at 19:25, Tim Graham 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.
--
You received this message because you are subscribed to the Google Groups
"Dja
13 matches
Mail list logo
