An easier path to upgrade from one LTS release to another

[Abdullah Esmail]

Hello,
I apologize if this has been discussed already. I searched the topics, but 
didn't find anything.
First, I'd like to thank all of you for the truly amazing framework. I've 
been using django since 1.0 and it made my life much more easier and 
enjoyable and _stable_.

The reason why I love django is that stability is a high priority, 
backward-compatibility is well maintained and clear, crystal-clear and 
extra-detailed documentation, the "batteries-included" aspect, based on 
python, and the steady and stable evolution of the framework. Everything is 
well put together in an almost-perfect package. Thank you.

To my main issue, have you explored the possibility of creating a direct 
path from one LTS release to the next?
I think the "official" way of doing this now is to go through all releases 
in-between (1.4 -> 1.5 -> 1.6 -> 1.7 -> 1.8).
It would be really great if there was a direct LTS-to-LTS path (1.4 -> 1.8).

I'm not sure if the new system check framework can play a role here to make 
this easier than before.
This might add a whole new layer of complexity and extra work, but I 
believe it's worth it.
If it makes any difference, I don't mind helping with this and actually 
bringing this feature to life.
I'm not that familiar with the internals of django, but I'm willing to 
learn and get my hands dirty.

I guess I should ask, is there a good reason why there is no direct upgrade 
path between LTS releases?
Do you guys think it's not worth the extra effort and the current way is an 
acceptable trade-off?

Thank you,

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/96e73e82-93fe-4ef7-92c4-ba67abb35b37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An easier path to upgrade from one LTS release to another

[Anssi Kääriäinen]

One approach worth consideration is dropping deprecated features only
after next LTS. This would mean that any non-deprecated feature that
is available in current LTS will also be available (but possibly
deprecated) in the next LTS. This should make a development model
where code is developed using latest stable release, and supported
using latest LTS a lot easier.

I don't belileve we can offer an official LTS-to-LTS upgrade guide
(maintaining one is simply too much work). You can of course try to do
that, but you'll likely get a better result by upgrading one point
release at a time.

 - Anssi

On Thu, May 7, 2015 at 11:04 AM, Abdullah Esmail
 wrote:
> Hello,
> I apologize if this has been discussed already. I searched the topics, but
> didn't find anything.
> First, I'd like to thank all of you for the truly amazing framework. I've
> been using django since 1.0 and it made my life much more easier and
> enjoyable and _stable_.
>
> The reason why I love django is that stability is a high priority,
> backward-compatibility is well maintained and clear, crystal-clear and
> extra-detailed documentation, the "batteries-included" aspect, based on
> python, and the steady and stable evolution of the framework. Everything is
> well put together in an almost-perfect package. Thank you.
>
> To my main issue, have you explored the possibility of creating a direct
> path from one LTS release to the next?
> I think the "official" way of doing this now is to go through all releases
> in-between (1.4 -> 1.5 -> 1.6 -> 1.7 -> 1.8).
> It would be really great if there was a direct LTS-to-LTS path (1.4 -> 1.8).
>
> I'm not sure if the new system check framework can play a role here to make
> this easier than before.
> This might add a whole new layer of complexity and extra work, but I believe
> it's worth it.
> If it makes any difference, I don't mind helping with this and actually
> bringing this feature to life.
> I'm not that familiar with the internals of django, but I'm willing to learn
> and get my hands dirty.
>
> I guess I should ask, is there a good reason why there is no direct upgrade
> path between LTS releases?
> Do you guys think it's not worth the extra effort and the current way is an
> acceptable trade-off?
>
> Thank you,
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/96e73e82-93fe-4ef7-92c4-ba67abb35b37%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALMtK1E-F8i4_%2BYLH6KRzWMvuJEmr8geDDU9mUY9MFRudhLw0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: An easier path to upgrade from one LTS release to another

[Marc Tamlyn]

I'm not sure that would be a wise move - for people who don't keep up with
deprecation warnings but otherwise move one version at a time it would make
upgrading from an LTS to the following release 3 times harder than normal,
encouraging stagnation. This also affects third party applications who will
have similar problems.

Marc

On 7 May 2015 at 09:18, Anssi Kääriäinen  wrote:

> One approach worth consideration is dropping deprecated features only
> after next LTS. This would mean that any non-deprecated feature that
> is available in current LTS will also be available (but possibly
> deprecated) in the next LTS. This should make a development model
> where code is developed using latest stable release, and supported
> using latest LTS a lot easier.
>
> I don't belileve we can offer an official LTS-to-LTS upgrade guide
> (maintaining one is simply too much work). You can of course try to do
> that, but you'll likely get a better result by upgrading one point
> release at a time.
>
>  - Anssi
>
> On Thu, May 7, 2015 at 11:04 AM, Abdullah Esmail
>  wrote:
> > Hello,
> > I apologize if this has been discussed already. I searched the topics,
> but
> > didn't find anything.
> > First, I'd like to thank all of you for the truly amazing framework. I've
> > been using django since 1.0 and it made my life much more easier and
> > enjoyable and _stable_.
> >
> > The reason why I love django is that stability is a high priority,
> > backward-compatibility is well maintained and clear, crystal-clear and
> > extra-detailed documentation, the "batteries-included" aspect, based on
> > python, and the steady and stable evolution of the framework. Everything
> is
> > well put together in an almost-perfect package. Thank you.
> >
> > To my main issue, have you explored the possibility of creating a direct
> > path from one LTS release to the next?
> > I think the "official" way of doing this now is to go through all
> releases
> > in-between (1.4 -> 1.5 -> 1.6 -> 1.7 -> 1.8).
> > It would be really great if there was a direct LTS-to-LTS path (1.4 ->
> 1.8).
> >
> > I'm not sure if the new system check framework can play a role here to
> make
> > this easier than before.
> > This might add a whole new layer of complexity and extra work, but I
> believe
> > it's worth it.
> > If it makes any difference, I don't mind helping with this and actually
> > bringing this feature to life.
> > I'm not that familiar with the internals of django, but I'm willing to
> learn
> > and get my hands dirty.
> >
> > I guess I should ask, is there a good reason why there is no direct
> upgrade
> > path between LTS releases?
> > Do you guys think it's not worth the extra effort and the current way is
> an
> > acceptable trade-off?
> >
> > Thank you,
> >
> > --
> > 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 http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/django-developers/96e73e82-93fe-4ef7-92c4-ba67abb35b37%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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALMtK1E-F8i4_%2BYLH6KRzWMvuJEmr8geDDU9mUY9MFRudhLw0Q%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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HbBcZUddv8pNXXR%3DMz3S2vEHOK990yKqhCGzQ7Tb5XSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

MigrationTestCase

[Tom Linford]

At Robinhood, we've been using a custom in-house MigrationTestCase for 
testing migrations that we'd like to contribute, but want to check the API 
of it before contributing it. Here's the definition of the class:

class MigrationTestCase(TransactionTestCase):
"""
app_label: name of app (ie. "users" or "polls")
(start|dest)_migration_name: name of migration in app
(e.g. "0001_initial")
additional_dependencies: list of tuples of `(app_label, 
migration_name)`.
Add any additional migrations here that need to be included in the
generation of the model states.

Usage:

class TestCase(MigrationTestCase):
app_label = ...
start_migration_name = ...
dest_migration_name = ...
additional_dependencies = ...

def setUp(self):
# Create models with regular orm
super(TestCase, self).setUp()
# Create models with start orm. Access model with:
# self.start_models[""][""]
# Note that model_name must be all lower case, you can just do:
# ._meta.model_name to get the model_name

def test(self):
# Still using start orm
self.migrate_to_dest()
# Now, you can access dest models with:
# self.dest_models[""][""]
"""
app_label = None
start_migration_name = None
dest_migration_name = None
additional_dependencies = []


Let me know if this API is agreeable and I can make a PR for this feature.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8818bf72-aa66-4351-9177-e6e0f6605386%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An easier path to upgrade from one LTS release to another

[Tom Evans]

On Thu, May 7, 2015 at 9:04 AM, Abdullah Esmail
 wrote:
> Hello,
> I apologize if this has been discussed already. I searched the topics, but
> didn't find anything.
> First, I'd like to thank all of you for the truly amazing framework. I've
> been using django since 1.0 and it made my life much more easier and
> enjoyable and _stable_.
>
> The reason why I love django is that stability is a high priority,
> backward-compatibility is well maintained and clear, crystal-clear and
> extra-detailed documentation, the "batteries-included" aspect, based on
> python, and the steady and stable evolution of the framework. Everything is
> well put together in an almost-perfect package. Thank you.
>
> To my main issue, have you explored the possibility of creating a direct
> path from one LTS release to the next?
> I think the "official" way of doing this now is to go through all releases
> in-between (1.4 -> 1.5 -> 1.6 -> 1.7 -> 1.8).
> It would be really great if there was a direct LTS-to-LTS path (1.4 -> 1.8).
>
> I'm not sure if the new system check framework can play a role here to make
> this easier than before.
> This might add a whole new layer of complexity and extra work, but I believe
> it's worth it.
> If it makes any difference, I don't mind helping with this and actually
> bringing this feature to life.
> I'm not that familiar with the internals of django, but I'm willing to learn
> and get my hands dirty.
>
> I guess I should ask, is there a good reason why there is no direct upgrade
> path between LTS releases?
> Do you guys think it's not worth the extra effort and the current way is an
> acceptable trade-off?
>
> Thank you,

What would this feature look like? In order to go from one LTS to the
next LTS, you will need to do various things in turn, in order to
reflect the reality of changing 4 (or however many) minor versions one
at one time.

The easiest way to do that is to step through each of the intermediate
versions release notes in turn, applying the changes for that release
before moving on to the next one. I don't see what advantage collating
them all in to one document would have, given that you will still need
to do each set of steps in turn.

Cheers

Tom

PS: We are following this approach at $JOB - stick to LTS until the
next LTS and then upgrade via each minor release. Or I guess "will
be", 1.8 being only the second LTS ;)

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFHbX1JSurjb11HKhjVUa%2BHCOr7B6Yw1Kjh7Pi_S17Ua7m1Jsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: An easier path to upgrade from one LTS release to another

[Anssi Kääriäinen]

On Thu, May 7, 2015 at 11:34 AM, Marc Tamlyn  wrote:
> I'm not sure that would be a wise move - for people who don't keep up with
> deprecation warnings but otherwise move one version at a time it would make
> upgrading from an LTS to the following release 3 times harder than normal,
> encouraging stagnation.

The other side of this coin is that you get painless upgrades to the
latest LTS from the latest stable version. So, with a bit of
exaggeration, one could say that our current model encourages
stagnation to non-LTS versions.


 - Anssi

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALMtK1EC%2B9nakK2MjW%2B5mV3Nyt10XbQi2vTw6_WCfDwQ2GQLJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: An easier path to upgrade from one LTS release to another

[Marc Tamlyn]

You only get painless upgrades from one LTS to the next *if* you don't have
any deprecation warnings in your code on the previous LTS. Whilst the
"getting it working" step from one LTS direct to the next should be fairly
easy, you're likely to be faced with just as large a set of deprecation
issues on that new LTS issues you would have had to fix to get it working.
This does have some benefit for a quick update for security support or
similar, however I think there's a good chance it will make the *next* LTS
more painful as those warnings will not have been eliminated.

Then again, I don't work in an LTS environment, and no one has been working
in such a setup with django through several LTS versions to see what
happens.

On 7 May 2015 at 12:41, Anssi Kääriäinen  wrote:

> On Thu, May 7, 2015 at 11:34 AM, Marc Tamlyn 
> wrote:
> > I'm not sure that would be a wise move - for people who don't keep up
> with
> > deprecation warnings but otherwise move one version at a time it would
> make
> > upgrading from an LTS to the following release 3 times harder than
> normal,
> > encouraging stagnation.
>
> The other side of this coin is that you get painless upgrades to the
> latest LTS from the latest stable version. So, with a bit of
> exaggeration, one could say that our current model encourages
> stagnation to non-LTS versions.
>
>
>  - Anssi
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALMtK1EC%2B9nakK2MjW%2B5mV3Nyt10XbQi2vTw6_WCfDwQ2GQLJQ%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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1GR31cYY-yq0A4RcacgAn%3DO2g4kwgmLWm_fR40iQ%2B4R6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Tim Graham]

The survey is now "live". I saved the original responses separately, but 
some questions have been added or changed, so please respond again if you 
are willing. Thanks again for everyone's help and feedback in constructing 
the questions and I look forward to sharing the results.

On Saturday, May 2, 2015 at 8:27:34 PM UTC-4, Tim Graham wrote:
>
> I made a few edits based on recent feedback. I'll publicize it via the 
> djangoproject.com some time next week.
>
> On Wednesday, April 29, 2015 at 1:59:20 AM UTC-4, Markus Holtermann wrote:
>>
>> It's an amazing idea. Thanks for putting it up, Aymeric and Tim!
>>
>> Can we add a question regarding usage of test frameworks (i.e., 
>> unittest2, py.test, nose) similar to "Which popular third-party apps do you 
>> rely on?" For example "Which test frameworks do you use?" - "unittest2, 
>> py.test, nose, other". That would allow us to see if we should / can 
>> include features in django.test that may require a specific framework 
>> without excluding too many people of our community.
>>
>> /Markus
>>
>> On Monday, April 27, 2015 at 9:59:24 PM UTC+2, Thorsten Sanders wrote:
>>>
>>>  I wrote in that thread too why I dont like such fast releases and at 
>>> least someone else asked too to give more options on that one question, on 
>>> the developer mailing list its kinda only some people who are writing not 
>>> reflecting all the developers such an survey maybe reach more of them and 
>>> then the answer about such an important question shouldnt be reduced to 3 
>>> little options a handfull people decided on, that wouldnt reflect what 
>>> people really want if they cant choose an real answer.
>>>
>>> Am 27.04.2015 02:46, schrieb Tim Graham:
>>>  
>>> The idea of the release schedule question is to form consensus on the 
>>> options that have already been proposed in the "1.9 release planning 
>>> "
>>>  
>>> thread. If you have a different idea, please propose it there.
>>>
>>> On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote: 

  I like the idea of an survey, but find the release question with only 
 3 options quite limited, how about to allow there to put own numbers 
 instead of giving fixed answers or at least an other field?

 Am 25.04.2015 14:29, schrieb Tim Graham:
  
 Aymeric and I put together a draft:


 https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform

 All questions are optional so you can just click through it to view the 
 questions. We'll probably clear any responses before its finalized anyway.

 Let us know if you think we should make any additions or changes.

 On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano 
 wrote: 
>
> Great idea. 
> The questions look good enough to me.
>
>  I love django-apps or libraries shipped in python packages. One of 
> the reason I love Django is the fact that it didn't frenetically add 
> stuff 
> to the framework just because it's cool.
> The good thing of python packages is that you can get some data from 
> pypi (downloads) and github (clones). But we can't do that with contrib 
> apps unfortunately.
>
>  Federico
>
>
> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote: 
>>
>> I had an idea to conduct a survey to get a sense of how developers 
>> are using Django. I first had the idea when the question of maintenance 
>> of 
>> the Oracle GIS backend came up. We really have no idea whether or not 
>> anyone is actually using that backend, and it would be helpful to know 
>> so 
>> we are not wasting resources on unused features. Also there's the 
>> question 
>> of how often to release Django. I think it would be nice to make that 
>> decision based on some data from the community.
>>
>> Is anyone is interested in coordinating such a survey (collating 
>> questions, preparing the online survey, etc.).
>>
>> Some question ideas to get started:
>>
>> Which database backend(s) do you use?
>> [ ] Checkbox for each one
>>
>> Which contrib apps do you use?
>> [ ] Checkbox for each one
>>
>> How often would you like to see new major version of Django released?
>> [ ] List some options, probably between 6 and 9 months.
>>
>> Describe which version of Django you use (check all the apply):
>> [ ] I only use long-term support releases.
>> [ ] I upgrade to the latest stable version as quickly as possible.
>> [ ] I run off of master.
>> [ ] I upgrade Django when the version I am using is nearing the end 
>> of its support (or after).
>> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>>  
>   -- 
 You received this message because you are subscribed to the Goo

Re: An easier path to upgrade from one LTS release to another

[Tim Graham]

I think there is some merit to reconsidering the deprecation schedule as 
Anssi suggests. What I have seen is that most third-party apps didn't 
consider dropping support for the previous LTS (1.4) until the next LTS 
(1.8) was released. This meant that all these projects had to implement 
their own compatibility shims (instead of using Django's) once they wanted 
to add support for Django 1.6+ because the compatibility shims for 
deprecated features in 1.4 were dropped in Django. This resulted in ugly 
code with lots of conditional version branches, etc. I'll keep thinking 
about this as we decide the release schedule going forward.

On Thursday, May 7, 2015 at 10:14:34 AM UTC-4, Marc Tamlyn wrote:
>
> You only get painless upgrades from one LTS to the next *if* you don't 
> have any deprecation warnings in your code on the previous LTS. Whilst the 
> "getting it working" step from one LTS direct to the next should be fairly 
> easy, you're likely to be faced with just as large a set of deprecation 
> issues on that new LTS issues you would have had to fix to get it working. 
> This does have some benefit for a quick update for security support or 
> similar, however I think there's a good chance it will make the *next* LTS 
> more painful as those warnings will not have been eliminated.
>
> Then again, I don't work in an LTS environment, and no one has been 
> working in such a setup with django through several LTS versions to see 
> what happens.
>
> On 7 May 2015 at 12:41, Anssi Kääriäinen > 
> wrote:
>
>> On Thu, May 7, 2015 at 11:34 AM, Marc Tamlyn > > wrote:
>> > I'm not sure that would be a wise move - for people who don't keep up 
>> with
>> > deprecation warnings but otherwise move one version at a time it would 
>> make
>> > upgrading from an LTS to the following release 3 times harder than 
>> normal,
>> > encouraging stagnation.
>>
>> The other side of this coin is that you get painless upgrades to the
>> latest LTS from the latest stable version. So, with a bit of
>> exaggeration, one could say that our current model encourages
>> stagnation to non-LTS versions.
>>
>>
>>  - Anssi
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CALMtK1EC%2B9nakK2MjW%2B5mV3Nyt10XbQi2vTw6_WCfDwQ2GQLJQ%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 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7de71cc0-a0fb-4749-8065-8972219b2df9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An easier path to upgrade from one LTS release to another

[Carl Meyer]

On 05/07/2015 08:53 AM, Tim Graham wrote:
> I think there is some merit to reconsidering the deprecation schedule as
> Anssi suggests. What I have seen is that most third-party apps didn't
> consider dropping support for the previous LTS (1.4) until the next LTS
> (1.8) was released. This meant that all these projects had to implement
> their own compatibility shims (instead of using Django's) once they
> wanted to add support for Django 1.6+ because the compatibility shims
> for deprecated features in 1.4 were dropped in Django. This resulted in
> ugly code with lots of conditional version branches, etc. I'll keep
> thinking about this as we decide the release schedule going forward.

I agree with this. I think by far the biggest thing we could do to make
it easier to go from LTS to LTS is to make it easier for third-party
apps to support two LTS releases at once. Guaranteeing that no API which
is un-deprecated in one LTS will be removed until after the following
LTS would make that massively easier.

Carl


-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/554B8A86.30402%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

No way to optimize batch deletion

[Antoine Catton]

Hello,

django-treebeard [1] has an optimized batch deletion for its models. [2]

The main reason is because post_delete signals are called for each 
objects. And custom deletion in treebeard can be done in batch.


I was reading Django's code [3] and it looks like there's no way to hook 
into _raw_delete() or DeleteQuery.delete_batch().


The only way is to hook into signals.post_delete.

This causes problems if we have something like this:

  class A(treebeard.MP_Tree):
  b = ForeignKey('B')

  class B(models.Model):
  a = IntegerField()

If we run:
  B.objects.filter(expression).delete()
Because Treebeard is overriding A.objects.delete(), the custom delete() 
will never be called on the tree, and the tree will be inconsistent.


One solution I can think of, would be to add a pre/post batch_delete 
signal. But I'm open to any other solution.



[1] 
[2] 

[3] 



--
Antoine Catton
Software Engineer at Fusionbox, Inc.


--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/554BF717.50503%40fusionbox.com.
For more options, visit https://groups.google.com/d/optout.

Re: No way to optimize batch deletion

[Michael Manfre]

A pre/post batch_delete signal would be useful for the usage you describe.
There would likely be confusion with its usage because unlike post_delete,
the batch_delete signals would not be able to provide actual records. The
best it could do would be to provide the queryset and the deletion count on
the post. The topic of batch deletion signaling has come up before, but I
don't remember the outcome (or whether it was on here or IRC). I'll try to
find it and report back when I get to a more capable device.

Regards,
Michael Manfre

On Thu, May 7, 2015 at 7:36 PM, Antoine Catton 
wrote:

> Hello,
>
> django-treebeard [1] has an optimized batch deletion for its models. [2]
>
> The main reason is because post_delete signals are called for each
> objects. And custom deletion in treebeard can be done in batch.
>
> I was reading Django's code [3] and it looks like there's no way to hook
> into _raw_delete() or DeleteQuery.delete_batch().
>
> The only way is to hook into signals.post_delete.
>
> This causes problems if we have something like this:
>
>   class A(treebeard.MP_Tree):
>   b = ForeignKey('B')
>
>   class B(models.Model):
>   a = IntegerField()
>
> If we run:
>   B.objects.filter(expression).delete()
> Because Treebeard is overriding A.objects.delete(), the custom delete()
> will never be called on the tree, and the tree will be inconsistent.
>
> One solution I can think of, would be to add a pre/post batch_delete
> signal. But I'm open to any other solution.
>
>
> [1] 
> [2] <
> http://code.tabo.pe/django-treebeard/src/04ca69b7daf6390bb2130305cf1325df486d6b7e/treebeard/mp_tree.py?at=default#cl-51
> >
> [3] <
> https://github.com/django/django/blob/3baebf52aa0850de3ebadcbe1eda7e6e9a2c6c44/django/db/models/deletion.py#L284
> >
>
> --
> Antoine Catton
> Software Engineer at Fusionbox, Inc.
> 
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/554BF717.50503%40fusionbox.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBvZ2qE4VE8ZgzCOsAAgbQvwe6LCB3PULN%3Dc337pniZC4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Need help running Django's test suite on Oracle 12

[Tim Graham]

We have some instructions to help contributors run the Django test suite on 
Oracle, however, these instructions are for Oracle 11 and the virtual 
machine image provided by Oracle now uses Oracle 12c. I've tried to update 
the instructions, but it seems there are some changes in Oracle 12 related 
to user creation (common user vs. local user?) that I'm not easily figuring 
out. Any Oracle experts out there who can lend a hand?

https://code.djangoproject.com/wiki/OracleTestSetup

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/35f8e23c-2b39-49dc-9cac-abaf8bd58a7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Queryset values() differentiate between requests for model objects and model IDs

[Matt C]

If I have some models like so:

from django.db import models

class X(models.Model):
y = models.ForeignKey(Y)
... other fields ...

class Y(models.Model):
... some fields ...



... and I do a query like so:

X.objects.all().values('y')

... I get back a list of dictionaries that contain Y ID integers.

If I do a query like so:

X.objects.all().values('y_id')

...I get back a similar result, except for the keys in the dictionaries.

My proposal is to differentiate between those two calls and in the former 
case, instead of returning the same results as the latter case, return Y 
model objects.

Not only would this produce results that are more indicative of what the 
query is asking for, but it would extend the ORM in at least one area:
http://stackoverflow.com/questions/30113766/aggregrate-query-with-related-models-not-just-related-id-values

Those kinds of aggregrate queries would be possible.

As far as backwards compatibility is concerned, the old behaviour could 
occur with no key word argument to the values() call, but if a keyword 
argument like so:

X.objects.all().values('y', select_related=True)

...is specified, then my proposed behaviour could be executed.

What do you think?

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4adaa5a3-f6d3-4189-8bb5-83eb5c4f2648%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: An easier path to upgrade from one LTS release to another

[Tai Lee]

This sounds good. But will it significantly slow down the rollout of new 
features into Django that require deprecation? Also, could features that 
are deprecated in an LTS be dropped in the next non-LTS release? e.g. if 
1.8 still had a feature that was deprecated in 1.5, could it finally be 
removed in 1.9?


On Friday, May 8, 2015 at 1:53:59 AM UTC+10, Carl Meyer wrote:
>
> On 05/07/2015 08:53 AM, Tim Graham wrote: 
> > I think there is some merit to reconsidering the deprecation schedule as 
> > Anssi suggests. What I have seen is that most third-party apps didn't 
> > consider dropping support for the previous LTS (1.4) until the next LTS 
> > (1.8) was released. This meant that all these projects had to implement 
> > their own compatibility shims (instead of using Django's) once they 
> > wanted to add support for Django 1.6+ because the compatibility shims 
> > for deprecated features in 1.4 were dropped in Django. This resulted in 
> > ugly code with lots of conditional version branches, etc. I'll keep 
> > thinking about this as we decide the release schedule going forward. 
>
> I agree with this. I think by far the biggest thing we could do to make 
> it easier to go from LTS to LTS is to make it easier for third-party 
> apps to support two LTS releases at once. Guaranteeing that no API which 
> is un-deprecated in one LTS will be removed until after the following 
> LTS would make that massively easier. 
>
> Carl 
>
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ebcfc899-fe81-481d-9c00-9e66b5967c56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.