Re: Django 1.11 indexes

2017-01-29 Thread Adam Johnson 
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 Kucherivaiy 
wrote:

> Hi Everyone,
>
> 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 it stay like this for future release or 1st approach will be
> deprecated/removed later ?
>
>
> --
> 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/58719258-8ba3-4f9d-9042-
> b2003786ec2a%40googlegroups.com
> 
> .
> 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/CAMyDDM1sEsc7L0VTE%3D%3DqrxAzDQWS1UnSJzNP_jg6%2BfBC0mTY8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re-open ticket 25192

2017-01-29 Thread Florian Apolloner 


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 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/e984d61f-45bc-4620-a10f-91bf1113979c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.11 indexes

2017-01-29 Thread Shai Berger 
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 it stay like this for future release or 1st approach will be
> > deprecated/removed later ?
> > 
> 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*.
> 

Exactly. This is similar to the situation with Field(unique=True) vs. 
Meta.unique_together.

Re: Re-open ticket 25192

2017-01-29 Thread Markus Holtermann 

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.



Seems sensible, go ahead

--
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/e984d61f-45bc-4620-a10f-91bf1113979c%40googlegroups.com.
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/20170129160635.GB5396%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Need to get user_id outside of a view

2017-01-29 Thread Victor Porton 
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 file in a secret directory (directory
with a secret hash as its name) so that other users could not read it
without receiving an explicit link from the uploader.) I wrote code
like this:

class MyStorage(FileSystemStorage):
# ...

def get_user(self):
SessionStore =
import_module(settings.SESSION_ENGINE).SessionStore
s = SessionStore()
s.load()
# print({id: s[id] for id in s.keys()})  # FIXME
# user = apps.get_model('User').objects.get(id=s['user_id'])
return s['user_id']

This is set as

DEFAULT_FILE_STORAGE = 'xxx_storage_app.storage.MyStorage'

So I expect every form with a file to upload using MyStorage (and so
the upload algorithm depends on the current user).

But s behaves as an empty hash (without user_id element), as revealed
by the commented "FIXME" line.

We need either to make SessionStore to support this use case or
massively rewrite API to pass `request` to the form and ultimately to
the storage. I think we can do this without losing backward
compatibility using default function arguments.

It is a big API change, but it is necessary to support storage
dependent on the current user. It is a real and important use case for
our project.

Let us discuss the details, what is the best way to implement this in
future versions of Django.

Sorry for an offtopic, but can you advise me how to do it without
rewriting Django core?

-- 
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/1485713514.10180.3.camel%40narod.ru.
For more options, visit https://groups.google.com/d/optout.

Re: Need to get user_id outside of a view

2017-01-29 Thread Victor Porton 
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:10 PM UTC+2, Victor Porton wrote:
>
> 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 file in a secret directory (directory 
> with a secret hash as its name) so that other users could not read it 
> without receiving an explicit link from the uploader.) I wrote code 
> like this: 
>
> class MyStorage(FileSystemStorage): 
> # ... 
>
> def get_user(self): 
> SessionStore = 
> import_module(settings.SESSION_ENGINE).SessionStore 
> s = SessionStore() 
> s.load() 
> # print({id: s[id] for id in s.keys()})  # FIXME 
> # user = apps.get_model('User').objects.get(id=s['user_id']) 
> return s['user_id'] 
>
> This is set as 
>
> DEFAULT_FILE_STORAGE = 'xxx_storage_app.storage.MyStorage' 
>
> So I expect every form with a file to upload using MyStorage (and so 
> the upload algorithm depends on the current user). 
>
> But s behaves as an empty hash (without user_id element), as revealed 
> by the commented "FIXME" line. 
>
> We need either to make SessionStore to support this use case or 
> massively rewrite API to pass `request` to the form and ultimately to 
> the storage. I think we can do this without losing backward 
> compatibility using default function arguments. 
>
> It is a big API change, but it is necessary to support storage 
> dependent on the current user. It is a real and important use case for 
> our project. 
>
> Let us discuss the details, what is the best way to implement this in 
> future versions of Django. 
>
> Sorry for an offtopic, but can you advise me how to do it without 
> rewriting Django core? 
>

-- 
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/6db56f76-6ac0-4e24-b42b-3c5b800a749d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need to get user_id outside of a view

2017-01-29 Thread Aron Podrigal 
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

On Sun, Jan 29, 2017, 1:22 PM Victor Porton  wrote:

> 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:10 PM UTC+2, Victor Porton wrote:
>
> 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 file in a secret directory (directory
> with a secret hash as its name) so that other users could not read it
> without receiving an explicit link from the uploader.) I wrote code
> like this:
>
> class MyStorage(FileSystemStorage):
> # ...
>
> def get_user(self):
> SessionStore =
> import_module(settings.SESSION_ENGINE).SessionStore
> s = SessionStore()
> s.load()
> # print({id: s[id] for id in s.keys()})  # FIXME
> # user = apps.get_model('User').objects.get(id=s['user_id'])
> return s['user_id']
>
> This is set as
>
> DEFAULT_FILE_STORAGE = 'xxx_storage_app.storage.MyStorage'
>
> So I expect every form with a file to upload using MyStorage (and so
> the upload algorithm depends on the current user).
>
> But s behaves as an empty hash (without user_id element), as revealed
> by the commented "FIXME" line.
>
> We need either to make SessionStore to support this use case or
> massively rewrite API to pass `request` to the form and ultimately to
> the storage. I think we can do this without losing backward
> compatibility using default function arguments.
>
> It is a big API change, but it is necessary to support storage
> dependent on the current user. It is a real and important use case for
> our project.
>
> Let us discuss the details, what is the best way to implement this in
> future versions of Django.
>
> Sorry for an offtopic, but can you advise me how to do it without
> rewriting Django core?
>
> --
> 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/6db56f76-6ac0-4e24-b42b-3c5b800a749d%40googlegroups.com
> 
> .
> 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/CANJp-yjo5zT9eh4JtPW7aA%3DPXjXGX0xSpHQUA75CSVU%2BhWpMYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

2017-01-29 Thread Proxy 
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... So yeah, It looks like 
   antipattern. +1 for dict settings.
   2. *Fixed* django sites that proposed dict in settings would do the job 
   quite easily. +1 for dict settings.
   3. *Dynamic* django sites that implements SaaS? Hay, we're now in 2017 
   It needs not only more fields bound to Site model than domain and verbose 
   name, but can't relate on server restart to reload dict settings. And whose 
   gonna manually change that settings?! -inf for dict settings, +0 model 
   sites.

Actually django.contrib.settings needs to be SWAPPABLE. Then it will 
receive +100. (Oooohh... Someone already proposed this. Even with code 
sample -> https://code.djangoproject.com/ticket/22779. 3 years ago and 
ticket still open... How typical... :/)


In my project I'm case #2, but I still need a bunch of additional fields to 
provide for Site. Icons, descriptions, https flags. Think with SaaS and 
you'll know the drill.

Currently making it possible equals ton of hackish lines and definitely 
more DB queries.


Django needs to squish more juice from sites framework. Even for simple 
uses - Site query is cached anyways. I agree that majority of django 
powered sites are using SITE_ID = 1, and making dummy instances can be 
useless overhead, but replacing sites configuration by static dict settings 
will totally kill the functionality. Sites, when used, should be dynamic 
and cached. And remember -> sites can be bound dynamically with 
request.get_host(), so there is no fixed settings 
(https://github.com/django/django/blob/3c447b108ac70757001171f7a4791f493880bf5b/django/contrib/sites/models.py#L63).

W dniu piątek, 29 stycznia 2016 21:45:02 UTC+1 użytkownik Tim Graham 
napisał:
>
> In another thread about adding a "scheme" field to the Site model [1], I 
> floated the idea of moving the data stored by the Site model into a setting:
>
> I've sometimes thought that the Site model violates the principle that you 
> shouldn't put configuration in your database. I guess there's some 
> usefulness to having a ForeignKey to the site, but... would it be feasible 
> to offer a SITES setting that could be used instead? e.g.
>
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
>
> Carl said:+1 to this, I've long felt that the Site model was an 
> anti-pattern. I don't know if it's worth deprecating and switching to a 
> different system, though; it'd be a relatively painful deprecation for 
> those using  it, I would guess.
>
> James said:  "In using Marten Kenbeek's URL dispatch rewrite branch, I've 
> found that using the pattern of defining some site configuration in your 
> settings is the way to go: it more easily allows you to have URL patterns 
> on multiple domain/scheme combinations. I use a dict similar to what Tim 
> has shown, and then use it to initialize my scheme/domain URL constraints 
> in my root urls.py."
>
> I'd like to get more feedback and ideas about this. Do you think we'll be 
> better off in the long run with a setting as opposed to storing the data in 
> the database? Maybe writing a new sites app that uses a setting instead of 
> trying to modify the existing models-based one would be a better plan.
>
> I think the hard problem to solve is what to do about the Redirect and 
> FlatPage models which have ForeignKey and ManyToManyField relations to the 
> Site model.
>
> Perhaps some outcome of this discussion plus considering what features of 
> related third-party tools like django-hosts [2] might be useful to 
> incorporate in Django itself would be worthy of a project like Google 
> Summer of Code.
>
> [1] 
> https://groups.google.com/d/topic/django-developers/CzxaPDe8fpI/discussion
> [2] https://github.com/jazzband/django-hosts
>

-- 
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/09f75d9f-7068-4d4f-a926-28dcedf0355b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.