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

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

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

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

Need help running Django's test suite on Oracle 12

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

Re: No way to optimize batch deletion

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

No way to optimize batch deletion

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

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

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

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

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

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

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,

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

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

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

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

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

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

MigrationTestCase

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

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

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

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

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

An easier path to upgrade from one LTS release to another

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