Hi Dmitry,
thanks for the alternative way, however it seems more a *complement *than a
replacement of DCP.
Indeed, your "rewriting" approach updates a codebase to support the latest
django API, but it raises a number of issues :
- how could it be applied to django reusable apps, installed via pi
Hi Pascal,
I'm unsure as to what problem you're trying to solve; if I understand
correctly, this project aims at making a "new"
Django behave like an "old" one.
I see a few possible use cases in the conversation:
* Running a legacy application (without new development) beyond the upstream
sup
An interesting bug has turned up in Channels where someone is trying to
remove a session using .flush(), but our decorator sees that it's been
modified and then re-saves it, thinking it needs to persist data.
What are people's opinions on changing flush() to also set modified=False
on sessions? Is
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'
I'm not sure offhand. Could you provide a link to the issue so we could
look at the details?
On Monday, January 23, 2017 at 1:45:48 PM UTC-5, Andrew Godwin wrote:
>
> An interesting bug has turned up in Channels where someone is trying to
> remove a session using .flush(), but our decorator sees
Here's the Channels issue underlying it:
https://github.com/django/channels/issues/477
For quick reference, the @channel_session decorator is something that wraps
a consumer, loading a session on the way in and saving it on the way out if
it changed, similar to how session middleware might work.
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
Sorry for the radio silence, I've been busy at work.
After re-reading things and thinking a bit more about it, I think Tim's
suggestion of just changing the default in a release is probably the right
idea. The warning + check does seem very bothersome; as Aymeric says, this
is very far from the co
Sorry for my radio/email silence, I had a lot of things to do at work and
wanted to think this through a bit more.
Looking again at the warning + check implementation, it is a bit messy. My
goal with the check was to get a message in front of users who need it, but
I suppose the release notes a
(I sent basically the same email twice because it looked to me like the
first was lost, didn't even show in my outbox :/)
On 23 January 2017 at 21:15, Adam Johnson wrote:
> Sorry for the radio silence, I've been busy at work.
>
> After re-reading things and thinking a bit more about it, I think
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
12 matches
Mail list logo
