Re: Composite Primary Keys

[bliyanage]

Sounds cool, I think we would totally use that. 

On Wednesday, February 17, 2016 at 1:55:15 AM UTC-8, Roger Gammans wrote:
>
> Hi, 
>
>
> We've got some patches that we are using in production, against 
> 1.8 . Out long term aim would be to get them ready for a PR , but I they 
> are missing all sorts of things, such unit tests and migrations (we 
> don't use migrations at the moment - long story, so these haven't been 
> tested). The other thing which I think is  maybe is some of the 
> prefetch_related API, I've had difficulties with it and just worked 
> around it in my app. 
>
> And it really needs another user at least to kick the tires which we 
> aren't exercising - we mainly use because we have a lot of intersection 
> tables of natural / 'foreign' keys and a legacy model which didn't add a 
> serialized Pk for these. 
>
> I'd also like to know how interested the core developers would be in 
> merging some support for this. 
>
>
>
> On Tue, 2016-02-16 at 17:38 -0800, Cristiano Coelho wrote: 
> > Hello there, 
> > 
> > What's the status for this? This 
> > (https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys) is 3 
> > years old (last edit) and the links on it are even older. Googling 
> > around only gave me some very old projects so it wasn't good neither. 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to 
> > django-d...@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/b2873ece-39bb-4536-b23d-d988c7122204%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/098addaa-a397-4016-913c-e1a3037d34e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

% vs {} string formatting for public APIs

[Jon Dufresne]

Hi,

I noticed that some Django public APIs use the % old-style string
formatting while others use the {} new-style formatting.

For example:

{} style

* success_url [0] (Converted to {} in 1.8)
* format_html [1]

% style

* ValidationError [2]
* related_name [3]


Is this difference intentional?

As success_url recently moved to {}, I'm guessing {} is Django's
preferred style?

If this different is not intentional, I would like to propose a change
to ValidationError to use the {} style formatting. This change would
go through the same deprecation path as used by success_url. Thoughts?

I think this would create a greater API consistency throughout the
framework. I think using a single, consistent string formatting API
follows the design philosophy "principle of least surprise".

Ultimately, I don't care what format is preferred, but I think one
should be used consistently.

I have created a proof of concept as to what this would mean as a
change. The change still requires new tests and docs; so it still WIP.

https://github.com/django/django/compare/master...jdufresne:remove-percent-placeholder

If there is support for this change, I would like to follow through a
ticket and finished PR.

Cheers,
Jon


[0] 
https://docs.djangoproject.com/en/1.9/ref/class-based-views/mixins-editing/#django.views.generic.edit.ModelFormMixin.success_url
[1] 
https://docs.djangoproject.com/en/1.9/ref/utils/#django.utils.html.format_html
[2] 
https://docs.djangoproject.com/en/1.9/ref/forms/validation/#raising-validationerror
[3] 
https://docs.djangoproject.com/en/1.9/topics/db/models/#be-careful-with-related-name

-- 
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/CADhq2b6RCWUhHFAAKsKeYbgpA35TQ%3DoQrHyR5vFL8UmTHn3QAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: remove support for unsalted password hashers?

[Tim Graham]

To answer my own question, I did a little experiment and cracked about 10% 
of the SHA1 password hashes in the djangoproject.com database in minutes on 
my several year old PC.

I think that's sufficiently weak to:
1. Make a blog post recommending that projects upgrade using the 
instructions in [1] 
2. Remove SHA1PasswordHasher from the default PASSWORD_HASHERS in Django 
1.10 to force projects to explicitly acknowledge use of an insecure hash if 
they require it.

[1] https://github.com/django/django/pull/6114

On Wednesday, February 10, 2016 at 5:16:11 PM UTC-5, Tim Graham wrote:
>
> Is salted SHA1 sufficiently insecure to remove it from the default 
> PASSWORD_HASHERS or should we leave it for now? Any project created before 
> pbkdf2 was introduced in Django 1.4 (March 2012) will likely have some SHA1 
> hashes unless all their users have logged in since. I've written 
> instructions on how to upgrade such passwords without requiring all your 
> users to login [1]. If it's warranted, we could make a blog post advising 
> this. 
>
> [1] https://github.com/django/django/pull/6114 
> 
>
> On Monday, February 8, 2016 at 3:12:28 PM UTC-5, Tim Graham wrote:
>>
>> Thanks for the feedback everyone. I've created a few action items:
>>
>> https://code.djangoproject.com/ticket/26187 - Remove weak password 
>> hashers from the default PASSWORD_HASHERS setting
>> https://code.djangoproject.com/ticket/26188 - Document how to wrap 
>> password hashers
>> https://github.com/django/djangoproject.com/issues/632 - Use a wrapped 
>> password hasher to upgrade SHA1 passwords
>>
>> On Saturday, February 6, 2016 at 3:56:00 AM UTC-5, Curtis Maloney wrote:
>>>
>>> I kept meaning to weigh in on this... but all my points have been made. 
>>>
>>> It sounds like the middle ground is to: 
>>>
>>> 1) remove them from the default list 
>>> 2) keep them in the codebase 
>>> 3) make them noisy (raise warnings) 
>>> 4) provide docs/tools on how to upgrade 
>>>
>>> Then we get "secure by default" (1), as well as "encouraging upgrades" 
>>> (3), whilst also "supporting slow-to-update installs" (4), and 
>>> "encouraging best practices" (3). 
>>>
>>>
>>> -- 
>>> C 
>>>
>>>
>>> On 06/02/16 19:51, Aymeric Augustin wrote: 
>>> > Yes, that would be good from the “security by default” standpoint. 
>>> This 
>>> > would also allow us to trim the full list of hashers which is repeated 
>>> > several times in the docs. 
>>> > 
>>> > -- 
>>> > Aymeric. 
>>> > 
>>> >> On 6 févr. 2016, at 00:03, Tim Graham >> >> > wrote: 
>>> >> 
>>> >> I would guess most users aren't customizing the default list of 
>>> >> hashers, so I'd rather remove weak hashers from the PASSWORD_HASHERS 
>>> >> setting and let anyone who needs to use a weak hasher define their 
>>> own 
>>> >> setting (at which point a warning probably isn't needed). Does that 
>>> >> seem okay? 
>>> >> 
>>> >> On Friday, February 5, 2016 at 3:20:41 PM UTC-5, Aymeric Augustin 
>>> wrote: 
>>> >> 
>>> >> Adding a check for weak password hashers could be a good 
>>> >> compromise to drive attention to the issue but make it reasonably 
>>> >> easy to ignore it if you need MD5 for compatibility with other 
>>> >> systems. 
>>> >> 
>>> >> -- 
>>> >> Aymeric. 
>>> >> 
>>> >>> On 5 févr. 2016, at 21:11, Sergei Maertens >> >>> > wrote: 
>>> >>> 
>>> >>> This is my main concern as well. I often migrate old Joomla or 
>>> >>> other PHP things that use md5, and it's really convenient that 
>>> >>> Django upgrades the passwords for free for me. 
>>> >>> 
>>> >>> Although I guess I could just write the hasher as part of the 
>>> >>> project and add it to the setting, but then that's an additional 
>>> >>> burding because you need to keep track of potential new hashers 
>>> >>> that get added in the default settings. 
>>> >>> 
>>> >>> On Friday, February 5, 2016 at 1:05:01 PM UTC+1, Rafał Pitoń 
>>> wrote: 
>>> >>> 
>>> >>> Will I still be able to implement unsalted hasher if I so 
>>> desire? 
>>> >>> 
>>> >>> Don't get me wrong, I understand thats pretty crappy way to 
>>> >>> store password, but there are times when you inherit large 
>>> >>> set of data from site that you are moving from some old PHP 
>>> >>> contraption that happens to be around since 2006, is big 
>>> >>> (>100 users), ran by company that dominates one of 
>>> >>> nation's markets and says "absolutely no" on making all 
>>> those 
>>> >>> housewifes reset passwords, and your passwords happen to use 
>>> >>> md5(md5(pass) + md5(pass)) for passwords? 
>>> >>> 
>>> >>> 
>>> >>> -- 
>>> >>> You received this message because you are subscribed to the 
>>> >>> Google Groups "Django developers 

Re: thinking about the admin's scope and its description in the docs

[Aymeric Augustin]

+1

-- 
Aymeric.

> On 17 févr. 2016, at 18:16, Marc Tamlyn  wrote:
> 
> That looks like a good balanced message to me.
> 
> On 17 February 2016 at 16:57, Tim Graham  > wrote:
> Here's another try for the docs:
> 
> One of the most powerful parts of Django is the automatic admin interface. It
> reads metadata from your models to provide a quick, model-centric interface
> where trusted users can manage content on your site. The admin's recommended
> use is limited to an organization's internal management tool. It's not 
> intended
> for building your entire front end around.
> 
> The admin has many hooks for customization, but beware of trying to use those
> hooks exclusively. If you need to provide a more process-centric interface
> that abstracts away the implementation details of database tables and fields,
> then it's probably time to write your own views.
> 
> 
> On Friday, February 12, 2016 at 4:30:07 AM UTC-5, Andy Baker wrote:
> > However, we NEVER had a client that was sufficiently familiar with what a 
> > database is or how data modeling works for this to ever suffice. 
> 
> I've got more than two dozen non-technical clients happily using the admin. 
> They also have no familiarity with data modelling but I'm not quite sure how 
> that would help or hinder them. The concept of a filterable list view and an 
> editable form luckily doesn't require discussing 4th normal form or the 
> benefits of relational algebra ;-)
> 
> On Thursday, 11 February 2016 19:47:43 UTC, Chris Foresman wrote:
> FWIW, we used to tell clients that Django offers a basic admin interface "for 
> free". However, we NEVER had a client that was sufficiently familiar with 
> what a database is or how data modeling works for this to ever suffice. The 
> first thing we always do on new project is immediately disable the admin and 
> simply design APIs that allow our front-end teams to build some kind of 
> custom dashboard/admin interface.
> 
> IME, the admin is "sufficient" for sysadmins or technically experienced 
> users, but in practice those are few and far between.
> 
> 
> 
> On Thursday, February 11, 2016 at 12:08:08 PM UTC-6, bliy...@rentlytics.com 
> <> wrote:
> While I think it's true that a process centric workflow (wizards, or hubs 
> anyone?) would be incredibly useful, that does not take away from the fact 
> that the model centric admins are also incredibly useful, and time saving.  
> It's so easy to add search, sorting, bulk actions, etc to an admin--these are 
> things I've often spent days or weeks working on in other systems.  With 
> django it is often a matter of minutes to add these incredibly common 
> features.  This is probably one of my favorite things about the django 
> framework.
> 
> On Wednesday, February 10, 2016 at 5:33:03 PM UTC-8, Curtis Maloney wrote:
> 
> 
> On 11/02/16 00:55, Andy Baker wrote: 
> > I can't help but feel that the "admin is very rudimentary and hard to 
> > customize" is perpetually overplayed by many in the community. Maybe I'm 
> > suffering Stockholm Syndrome but I'd like to raise a dissenting voice. 
> 
> I must admit I'm a large proponent of warning against getting caught up 
> in "Admin as my management console". 
> 
> As customisable as it can be, I find the problem to be it is a 
> data-centric view of your system, closely tied to the database models. 
> 
> IMHO a management interface for site should be a _process_ centric view, 
> abstracting away the implementation details of tables and fields. 
> 
> Perhaps a better way to think of it as the difference between a 
> "management" and a "maintenance" interface. 
> 
> True, in a lot of cases these can be the same thing, and for simpler 
> sites Admin works "just fine".  However, I've been on too many projects 
> that wind up spending a lot of time and effort customising Admin to do 
> things that would have been simpler in a custom view. 
> 
> Worse still, I've seen projects alter their schema design to accommodate 
> Admin's limitations [like lack of nested inlines] 
> 
> Is it possible to add other views to admin?  Sure... though it's not 
> clear, or well documented. 
> 
> Can documentation alone overcome this problem?  I'm not convinced it can. 
> 
> For some years now I've been proposing an investigation into slicing 
> Admin into two layers: a base "management interface framework" layer, 
> and "admin" built atop this framework. 
> 
> Then we can keep providing the Admin we all know and love, and also make 
> it easier for people to build their own management interfaces. 
> 
> However, I don't currently have the time [or admin familiarity] to 
> undertake this work. 
> 
> -- 
> Curtis 
> 
> -- 
> 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 

Re: thinking about the admin's scope and its description in the docs

[Marc Tamlyn]

That looks like a good balanced message to me.

On 17 February 2016 at 16:57, Tim Graham  wrote:

> Here's another try for the docs:
>
> One of the most powerful parts of Django is the automatic admin interface.
> It
> reads metadata from your models to provide a quick, model-centric interface
> where trusted users can manage content on your site. The admin's
> recommended
> use is limited to an organization's internal management tool. It's not
> intended
> for building your entire front end around.
>
> The admin has many hooks for customization, but beware of trying to use
> those
> hooks exclusively. If you need to provide a more process-centric interface
> that abstracts away the implementation details of database tables and
> fields,
> then it's probably time to write your own views.
>
>
> On Friday, February 12, 2016 at 4:30:07 AM UTC-5, Andy Baker wrote:
>>
>> > However, we NEVER had a client that was sufficiently familiar with what
>> a database is or how data modeling works for this to ever suffice.
>>
>> I've got more than two dozen non-technical clients happily using the
>> admin. They also have no familiarity with data modelling but I'm not quite
>> sure how that would help or hinder them. The concept of a filterable list
>> view and an editable form luckily doesn't require discussing 4th normal
>> form or the benefits of relational algebra ;-)
>>
>> On Thursday, 11 February 2016 19:47:43 UTC, Chris Foresman wrote:
>>>
>>> FWIW, we used to tell clients that Django offers a basic admin interface
>>> "for free". However, we NEVER had a client that was sufficiently familiar
>>> with what a database is or how data modeling works for this to ever
>>> suffice. The first thing we always do on new project is immediately disable
>>> the admin and simply design APIs that allow our front-end teams to build
>>> some kind of custom dashboard/admin interface.
>>>
>>> IME, the admin is "sufficient" for sysadmins or technically experienced
>>> users, but in practice those are few and far between.
>>>
>>>
>>>
>>> On Thursday, February 11, 2016 at 12:08:08 PM UTC-6,
>>> bliy...@rentlytics.com wrote:

 While I think it's true that a process centric workflow (wizards, or
 hubs anyone?) would be incredibly useful, that does not take away from the
 fact that the model centric admins are also incredibly useful, and time
 saving.  It's so easy to add search, sorting, bulk actions, etc to an
 admin--these are things I've often spent days or weeks working on in other
 systems.  With django it is often a matter of minutes to add these
 incredibly common features.  This is probably one of my favorite things
 about the django framework.

 On Wednesday, February 10, 2016 at 5:33:03 PM UTC-8, Curtis Maloney
 wrote:
>
>
>
> On 11/02/16 00:55, Andy Baker wrote:
> > I can't help but feel that the "admin is very rudimentary and hard
> to
> > customize" is perpetually overplayed by many in the community. Maybe
> I'm
> > suffering Stockholm Syndrome but I'd like to raise a dissenting
> voice.
>
> I must admit I'm a large proponent of warning against getting caught
> up
> in "Admin as my management console".
>
> As customisable as it can be, I find the problem to be it is a
> data-centric view of your system, closely tied to the database models.
>
> IMHO a management interface for site should be a _process_ centric
> view,
> abstracting away the implementation details of tables and fields.
>
> Perhaps a better way to think of it as the difference between a
> "management" and a "maintenance" interface.
>
> True, in a lot of cases these can be the same thing, and for simpler
> sites Admin works "just fine".  However, I've been on too many
> projects
> that wind up spending a lot of time and effort customising Admin to do
> things that would have been simpler in a custom view.
>
> Worse still, I've seen projects alter their schema design to
> accommodate
> Admin's limitations [like lack of nested inlines]
>
> Is it possible to add other views to admin?  Sure... though it's not
> clear, or well documented.
>
> Can documentation alone overcome this problem?  I'm not convinced it
> can.
>
> For some years now I've been proposing an investigation into slicing
> Admin into two layers: a base "management interface framework" layer,
> and "admin" built atop this framework.
>
> Then we can keep providing the Admin we all know and love, and also
> make
> it easier for people to build their own management interfaces.
>
> However, I don't currently have the time [or admin familiarity] to
> undertake this work.
>
> --
> Curtis
>
 --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django 

Re: thinking about the admin's scope and its description in the docs

[Tim Graham]

Here's another try for the docs:

One of the most powerful parts of Django is the automatic admin interface. 
It
reads metadata from your models to provide a quick, model-centric interface
where trusted users can manage content on your site. The admin's recommended
use is limited to an organization's internal management tool. It's not 
intended
for building your entire front end around.

The admin has many hooks for customization, but beware of trying to use 
those
hooks exclusively. If you need to provide a more process-centric interface
that abstracts away the implementation details of database tables and 
fields,
then it's probably time to write your own views.

On Friday, February 12, 2016 at 4:30:07 AM UTC-5, Andy Baker wrote:
>
> > However, we NEVER had a client that was sufficiently familiar with what 
> a database is or how data modeling works for this to ever suffice. 
>
> I've got more than two dozen non-technical clients happily using the 
> admin. They also have no familiarity with data modelling but I'm not quite 
> sure how that would help or hinder them. The concept of a filterable list 
> view and an editable form luckily doesn't require discussing 4th normal 
> form or the benefits of relational algebra ;-)
>
> On Thursday, 11 February 2016 19:47:43 UTC, Chris Foresman wrote:
>>
>> FWIW, we used to tell clients that Django offers a basic admin interface 
>> "for free". However, we NEVER had a client that was sufficiently familiar 
>> with what a database is or how data modeling works for this to ever 
>> suffice. The first thing we always do on new project is immediately disable 
>> the admin and simply design APIs that allow our front-end teams to build 
>> some kind of custom dashboard/admin interface.
>>
>> IME, the admin is "sufficient" for sysadmins or technically experienced 
>> users, but in practice those are few and far between.
>>
>>
>>
>> On Thursday, February 11, 2016 at 12:08:08 PM UTC-6, 
>> bliy...@rentlytics.com wrote:
>>>
>>> While I think it's true that a process centric workflow (wizards, or 
>>> hubs anyone?) would be incredibly useful, that does not take away from the 
>>> fact that the model centric admins are also incredibly useful, and time 
>>> saving.  It's so easy to add search, sorting, bulk actions, etc to an 
>>> admin--these are things I've often spent days or weeks working on in other 
>>> systems.  With django it is often a matter of minutes to add these 
>>> incredibly common features.  This is probably one of my favorite things 
>>> about the django framework.
>>>
>>> On Wednesday, February 10, 2016 at 5:33:03 PM UTC-8, Curtis Maloney 
>>> wrote:



 On 11/02/16 00:55, Andy Baker wrote: 
 > I can't help but feel that the "admin is very rudimentary and hard to 
 > customize" is perpetually overplayed by many in the community. Maybe 
 I'm 
 > suffering Stockholm Syndrome but I'd like to raise a dissenting 
 voice. 

 I must admit I'm a large proponent of warning against getting caught up 
 in "Admin as my management console". 

 As customisable as it can be, I find the problem to be it is a 
 data-centric view of your system, closely tied to the database models. 

 IMHO a management interface for site should be a _process_ centric 
 view, 
 abstracting away the implementation details of tables and fields. 

 Perhaps a better way to think of it as the difference between a 
 "management" and a "maintenance" interface. 

 True, in a lot of cases these can be the same thing, and for simpler 
 sites Admin works "just fine".  However, I've been on too many projects 
 that wind up spending a lot of time and effort customising Admin to do 
 things that would have been simpler in a custom view. 

 Worse still, I've seen projects alter their schema design to 
 accommodate 
 Admin's limitations [like lack of nested inlines] 

 Is it possible to add other views to admin?  Sure... though it's not 
 clear, or well documented. 

 Can documentation alone overcome this problem?  I'm not convinced it 
 can. 

 For some years now I've been proposing an investigation into slicing 
 Admin into two layers: a base "management interface framework" layer, 
 and "admin" built atop this framework. 

 Then we can keep providing the Admin we all know and love, and also 
 make 
 it easier for people to build their own management interfaces. 

 However, I don't currently have the time [or admin familiarity] to 
 undertake this work. 

 -- 
 Curtis 

>>>

-- 
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 

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

[Noemi]

Well, that made me sad (and confused) yesterday when I suddenly couldn't 
find docs via either djangoproject.com OR Google for some topics for 1.4 
(we're in the process of upgrading a large and crufty codebase from 1.4 to 
1.8 via 1.6).

Please at least don't eliminate the readthedocs versions in favor of 
downloads -- searchability is extremely important for those of us trying to 
work with older codebases and bring them up to date!

On Tuesday, February 16, 2016 at 11:11:00 PM UTC-5, Tim Graham wrote:
>
> I removed the 1.4, 1.5, and 1.6 docs from docs.djangoproject.com today. 
> They are still available on readthedocs. I've spent more than a couple 
> hours recently debugging some problems related to documentation builds 
> there. Some are described in 
> https://github.com/django/djangoproject.com/issues/627, otherwise are 
> related to elasticsearch (timeouts due to indexing so many documents, I 
> think). I hope removing old docs versions will help to reduce the 
> maintenance overhead of these tasks. Also, a stale link in the docs was 
> pointing to a site with adult content. I backported the fix as far back as 
> 1.4 today.
>
> On Monday, April 13, 2015 at 11:08:59 AM UTC-4, Florian Apolloner wrote:
>>
>> As long as it doesn't hurt we can keep em there -- remove as soon as they 
>> cause a problem ;)
>>
>> On Monday, April 13, 2015 at 4:30:01 PM UTC+2, Tim Graham wrote:
>>>
>>> I just discontinued the 1.3 docs on docs.djangoproject.com, they are 
>>> still available on django.readthedocs.org. Do you think we should keep 
>>> it there or not?
>>>
>>> On Thursday, August 7, 2014 at 7:45:15 AM UTC-4, Tim Graham wrote:

 I'm in favor of discontinuing older version of the docs. I recently 
 fixed the 1.3 documentation builder since there were several complaints, 
 but no one has complained about 1.2.

 On Thursday, August 7, 2014 7:32:25 AM UTC-4, Areski Belaid wrote:
>
> Hi Folks,
>
> I wanted to open a discussion regarding the following ticket 
> https://code.djangoproject.com/ticket/23042
>
> To summarize briefly, you may notice that we can search doc for Django 
> version 1.2 (for example 
> https://docs.djangoproject.com/search/?q=forms=4) but the 
> links in the result won't work.
>
>
> As Baptiste (IRC bmispelon) explained on IRC, we may have 2 approach 
> to solve this problem:
>
> 1) Fix the docs builder for versions < 1.2 (at the moment the 
> doc-building process is broken on old branches due to different version 
> of 
> Sphinx)
>
> 2) Discontinue older Django docs version and decide a policy regarding 
> doc hosting
>
>
> What do you think?
>
>
> -- 
> //Areski
>
>

-- 
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/fcd25f52-5614-4cea-86ea-fb6963d3334a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

[Sergei Maertens]

+1

Yes, you should upgrade, but the reality is that some people have old 
versions lying around. They should be _somewhere_, be it 'hard' to find. A 
PDF or Epub is fine as well, that removes the need to maintain the build of 
the docs for unsupported versions.

On Wednesday, February 17, 2016 at 10:30:57 AM UTC+1, Marc Tamlyn wrote:
>
> I see no reason to remove old versions from readthedocs.
>
> On 17 February 2016 at 04:22, Felipe Prenholato  > wrote:
>
>> I was catch by that change today and found the docs in 
>> http://django.readthedocs.org/en/1.5.x/.
>>
>> I wan't to suggest that for documentations that Django will remove from 
>> docs.djangoproject.com and from django.readthedocs.org we keep instead 
>> links to download PDFs / epubs / HTML zips in some place that is easy to 
>> find and so users can download it. Maybe some page like "Older versions" 
>> inside documentation.
>>
>> Well, just a thought :).
>>
>> Thx, Felipe.
>>
>> Felipe Prenholato.
>> Home page: http://devwithpassion.com | http://chronosbox.org/blog
>> GitHub: http://github.com/chronossc/ | Twitter: 
>> http://twitter.com/chronossc
>> LinkedIn: http://br.linkedin.com/in/felipeprenholato/
>>
>> 2016-02-17 2:10 GMT-02:00 Tim Graham :
>>
>>> I removed the 1.4, 1.5, and 1.6 docs from docs.djangoproject.com today. 
>>> They are still available on readthedocs. I've spent more than a couple 
>>> hours recently debugging some problems related to documentation builds 
>>> there. Some are described in 
>>> https://github.com/django/djangoproject.com/issues/627, otherwise are 
>>> related to elasticsearch (timeouts due to indexing so many documents, I 
>>> think). I hope removing old docs versions will help to reduce the 
>>> maintenance overhead of these tasks. Also, a stale link in the docs was 
>>> pointing to a site with adult content. I backported the fix as far back as 
>>> 1.4 today.
>>>
>>> On Monday, April 13, 2015 at 11:08:59 AM UTC-4, Florian Apolloner wrote:

 As long as it doesn't hurt we can keep em there -- remove as soon as 
 they cause a problem ;)

 On Monday, April 13, 2015 at 4:30:01 PM UTC+2, Tim Graham wrote:
>
> I just discontinued the 1.3 docs on docs.djangoproject.com, they are 
> still available on django.readthedocs.org. Do you think we should 
> keep it there or not?
>
> On Thursday, August 7, 2014 at 7:45:15 AM UTC-4, Tim Graham wrote:
>>
>> I'm in favor of discontinuing older version of the docs. I recently 
>> fixed the 1.3 documentation builder since there were several complaints, 
>> but no one has complained about 1.2.
>>
>> On Thursday, August 7, 2014 7:32:25 AM UTC-4, Areski Belaid wrote:
>>>
>>> Hi Folks,
>>>
>>> I wanted to open a discussion regarding the following ticket 
>>> https://code.djangoproject.com/ticket/23042
>>>
>>> To summarize briefly, you may notice that we can search doc for 
>>> Django version 1.2 (for example 
>>> https://docs.djangoproject.com/search/?q=forms=4) but the 
>>> links in the result won't work.
>>>
>>>
>>> As Baptiste (IRC bmispelon) explained on IRC, we may have 2 approach 
>>> to solve this problem:
>>>
>>> 1) Fix the docs builder for versions < 1.2 (at the moment the 
>>> doc-building process is broken on old branches due to different version 
>>> of 
>>> Sphinx)
>>>
>>> 2) Discontinue older Django docs version and decide a policy 
>>> regarding doc hosting
>>>
>>>
>>> What do you think?
>>>
>>>
>>> -- 
>>> //Areski
>>>
>>> -- 
>>> 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-develop...@googlegroups.com .
>>> To post to this group, send email to django-d...@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/8c2638b5-6604-4bd4-b470-9096aee14b69%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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> 

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

[Daniel Chimeno]

IMHO We should keep the older version of docs somewhere, ReadTheDocs it's 
fine.
But we can't only remove them. We may notice the users instead of returning 
a simple 404.
There are a lot of people still using those versions.
To keep happy search engines, we should give a 301 to somewhere, not sure 
if we should do it or not.



El jueves, 7 de agosto de 2014, 13:32:25 (UTC+2), Areski Belaid escribió:
>
> Hi Folks,
>
> I wanted to open a discussion regarding the following ticket 
> https://code.djangoproject.com/ticket/23042
>
> To summarize briefly, you may notice that we can search doc for Django 
> version 1.2 (for example 
> https://docs.djangoproject.com/search/?q=forms=4) but the links 
> in the result won't work.
>
>
> As Baptiste (IRC bmispelon) explained on IRC, we may have 2 approach to 
> solve this problem:
>
> 1) Fix the docs builder for versions < 1.2 (at the moment the doc-building 
> process is broken on old branches due to different version of Sphinx)
>
> 2) Discontinue older Django docs version and decide a policy regarding doc 
> hosting
>
>
> What do you think?
>
>
> -- 
> //Areski
>
>

-- 
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/ba425446-63fb-4039-b238-443adac456ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite Primary Keys

[Roger Gammans]

Hi,


We've got some patches that we are using in production, against
1.8 . Out long term aim would be to get them ready for a PR , but I they
are missing all sorts of things, such unit tests and migrations (we
don't use migrations at the moment - long story, so these haven't been
tested). The other thing which I think is  maybe is some of the
prefetch_related API, I've had difficulties with it and just worked
around it in my app. 

And it really needs another user at least to kick the tires which we
aren't exercising - we mainly use because we have a lot of intersection
tables of natural / 'foreign' keys and a legacy model which didn't add a
serialized Pk for these.

I'd also like to know how interested the core developers would be in
merging some support for this.



On Tue, 2016-02-16 at 17:38 -0800, Cristiano Coelho wrote:
> Hello there,
> 
> What's the status for this? This
> (https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys) is 3
> years old (last edit) and the links on it are even older. Googling
> around only gave me some very old projects so it wasn't good neither.
> 
> -- 
> 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/b2873ece-39bb-4536-b23d-d988c7122204%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/1455702835.27233.10.camel%40gammascience.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [Discussion] Legacy documentation / Boken docs Django v1.2

[Marc Tamlyn]

I see no reason to remove old versions from readthedocs.

On 17 February 2016 at 04:22, Felipe Prenholato 
wrote:

> I was catch by that change today and found the docs in
> http://django.readthedocs.org/en/1.5.x/.
>
> I wan't to suggest that for documentations that Django will remove from
> docs.djangoproject.com and from django.readthedocs.org we keep instead
> links to download PDFs / epubs / HTML zips in some place that is easy to
> find and so users can download it. Maybe some page like "Older versions"
> inside documentation.
>
> Well, just a thought :).
>
> Thx, Felipe.
>
> Felipe Prenholato.
> Home page: http://devwithpassion.com | http://chronosbox.org/blog
> GitHub: http://github.com/chronossc/ | Twitter:
> http://twitter.com/chronossc
> LinkedIn: http://br.linkedin.com/in/felipeprenholato/
>
> 2016-02-17 2:10 GMT-02:00 Tim Graham :
>
>> I removed the 1.4, 1.5, and 1.6 docs from docs.djangoproject.com today.
>> They are still available on readthedocs. I've spent more than a couple
>> hours recently debugging some problems related to documentation builds
>> there. Some are described in
>> https://github.com/django/djangoproject.com/issues/627, otherwise are
>> related to elasticsearch (timeouts due to indexing so many documents, I
>> think). I hope removing old docs versions will help to reduce the
>> maintenance overhead of these tasks. Also, a stale link in the docs was
>> pointing to a site with adult content. I backported the fix as far back as
>> 1.4 today.
>>
>> On Monday, April 13, 2015 at 11:08:59 AM UTC-4, Florian Apolloner wrote:
>>>
>>> As long as it doesn't hurt we can keep em there -- remove as soon as
>>> they cause a problem ;)
>>>
>>> On Monday, April 13, 2015 at 4:30:01 PM UTC+2, Tim Graham wrote:

 I just discontinued the 1.3 docs on docs.djangoproject.com, they are
 still available on django.readthedocs.org. Do you think we should keep
 it there or not?

 On Thursday, August 7, 2014 at 7:45:15 AM UTC-4, Tim Graham wrote:
>
> I'm in favor of discontinuing older version of the docs. I recently
> fixed the 1.3 documentation builder since there were several complaints,
> but no one has complained about 1.2.
>
> On Thursday, August 7, 2014 7:32:25 AM UTC-4, Areski Belaid wrote:
>>
>> Hi Folks,
>>
>> I wanted to open a discussion regarding the following ticket
>> https://code.djangoproject.com/ticket/23042
>>
>> To summarize briefly, you may notice that we can search doc for
>> Django version 1.2 (for example
>> https://docs.djangoproject.com/search/?q=forms=4) but the
>> links in the result won't work.
>>
>>
>> As Baptiste (IRC bmispelon) explained on IRC, we may have 2 approach
>> to solve this problem:
>>
>> 1) Fix the docs builder for versions < 1.2 (at the moment the
>> doc-building process is broken on old branches due to different version 
>> of
>> Sphinx)
>>
>> 2) Discontinue older Django docs version and decide a policy
>> regarding doc hosting
>>
>>
>> What do you think?
>>
>>
>> --
>> //Areski
>>
>> --
>> 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/8c2638b5-6604-4bd4-b470-9096aee14b69%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/CADdUj3G%3DWaG7G3KJM-yZ_e21UsakW6K5ap3%2Brd1ScOxS8rqQWA%40mail.gmail.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