Re: Help needed with the MySQL max index length problem for Django 1.10

2015-12-29 Thread Aymeric Augustin
At that point, I'd prefer picking an arbitrary length that makes sense for the underlying data rather than one based on MySQL's current limitations. Name length sounds like an reasonable proxy for username length. A quick Google search turns up http://www.historyrundown.com/top-5-people-with-the-l

Re: structural & functional review of django documentation

2015-12-29 Thread Tim Graham
I've refined Daniele's explanation here: https://github.com/django/django/pull/5888 Let me know if it helps and what could be better. On Monday, December 28, 2015 at 11:31:30 PM UTC-5, Eric Holscher wrote: > > > > On Monday, December 28, 2015 at 4:52:36 PM UTC-8, Daniele Procida wrote: >> >> On

Re: delegating our static file serving

2015-12-29 Thread David Evans
I'd be very happy to help with this. Two things to mention: 1. When I first wrote WhiteNoise the FileResponse class didn't exist and so the only way I could access `wsgi.file_wrapper` was by wrapping the wsgi application directly and bypassing Django. Now we have the FileResponse class it would

Re: FK constraints are not checked at the end of nested atomic blocks

2015-12-29 Thread Gavin Wahl
What does it even mean for constraints to be checked at savepoint commit? I would expect this to not cause any errors: with atomic(): # insert invalid fk with atomic(check_deferred_constraints=True): # do stuff that doesn't invalidate any contraints # delet

Re: Help needed with the MySQL max index length problem for Django 1.10

2015-12-29 Thread Collin Anderson
I propose 150 to err on the longer side: https://github.com/django/django/pull/5891 On Tuesday, December 29, 2015 at 5:28:01 AM UTC-5, Aymeric Augustin wrote: > > At that point, I'd prefer picking an arbitrary length that makes sense for > the underlying data rather than one based on MySQL's cur

Re: Help needed with the MySQL max index length problem for Django 1.10

2015-12-29 Thread Collin Anderson
Though wouldn't mind 180 either. On Tue, Dec 29, 2015 at 2:55 PM, Collin Anderson wrote: > I propose 150 to err on the longer side: > https://github.com/django/django/pull/5891 > > On Tuesday, December 29, 2015 at 5:28:01 AM UTC-5, Aymeric Augustin wrote: >> >> At that point, I'd prefer picking

Re: structural & functional review of django documentation

2015-12-29 Thread Tim Allen
Tim: that's definitely a big help, but still a click away. I'm just brainstorming here, please bear with me! I think part of my confusion as a newbie is from the front page itself, at https://docs.djangoproject.com/ Now that I understand the concepts behind the documentation better (thanks Dan

Re: structural & functional review of django documentation

2015-12-29 Thread Tim Graham
The docs I proposed would be added to the front page. I'm not sure if I misunderstand what you meant by "still a click away"? To me, the front page is a topical guide that links to all documentation pages (topics/ref/howto) for each topic. I think it's useful, though I don't really use it mysel

Re: structural & functional review of django documentation

2015-12-29 Thread Eric Holscher
On Tuesday, December 29, 2015 at 2:17:31 PM UTC-8, Tim Graham wrote: > > > Turning the table of contents page into a CSS menu sounds like a possibly > worthwhile task. > > There is also an idea here for adding navigation breadcrumbs to the > documentation which might help: > https://github.com/

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-29 Thread martin f krafft
also sprach Shai Berger [2015-12-10 08:38 +1300]: > As far as I can see, you are trying to implement it in the model, > rather than as a new kind of field. Try to write > ExtendedGenericForeignKey, and I think things would look much > better... Hi, thanks for your response and sorry for taking su