Followed by https://code.djangoproject.com/ticket/27784 I'm gonna revive
this discussion about Sites contrib framework.
Let's sum up cases when django.contrib.sites can be used:
1. *Single* django site with totally no use of sites framework. Docs
tells us to make a dummy instance anyways.
I've had similar use cases where I needed access to the request in a number
of places. I've come to the conclusion that any code that is expected to
operate under wsgi (and only under wsgi, and not via management commands)
to use thread locals.
see https://github.com/nebstrebor/django-threadlocals
Probably a good way to solve this problem is to add `request` (with default
`None`) argument to `Model.save` method, which could then be passed to the
storage used for file fields.
Let us discuss if this is a good solution or can we invent something better.
On Sunday, January 29, 2017 at 8:12:1
See also
https://code.djangoproject.com/ticket/27786
I attempt to make file storage behavior dependent on the current user.
(In fact, I attempted to store the ID of the uploader of a given file
into the database, so that other users could not list or delete this
file. Also I tried to store the fi
Yeah, reopening and fixing in 1.11 sounds worth the effort. Thanks Shai!
/Markus
On Sun, Jan 29, 2017 at 02:12:49AM -0800, Florian Apolloner wrote:
On Sunday, January 29, 2017 at 12:02:21 AM UTC+1, Shai Berger wrote:
I suggest that we re-open this ticket and solve it in the 1.11.x branch.
On Sunday 29 January 2017 11:41:39 Adam Johnson wrote:
> On 28 January 2017 at 21:45, Vitaliy Kucherivaiy
> wrote:
> >
> > Do I understand this correctly - now there are 2 ways to make a single
> > field indexed in database:
> > - FieldClass(db_index=True)
> > - Model.Meta.indexes
> >
> > will
On Sunday, January 29, 2017 at 12:02:21 AM UTC+1, Shai Berger wrote:
>
> I suggest that we re-open this ticket and solve it in the 1.11.x branch.
>
Seems sensible, go ahead
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Dja
Afaik there is no deprecation plan for *db_index*, and I doubt it would be
since it would require lots of projects to update their models for no
particular gain. Probably best to think of *db_index* as a shortcut for
adding an index to *Meta.indexes*.
On 28 January 2017 at 21:45, Vitaliy Kucheriva
