Quel est le meilleur moyen de passer de Django 0.96 à 1.0?

Question

Dois-je essayer de mettre à niveau mon application existante ou de la réécrire à partir de rien, en enregistrant les éléments (modèles, etc.) que je peux?

Answer 1

Bien que cela dépende de ce que vous faites, la plupart des applications devraient pouvoir simplement mettre à niveau, puis réparer tout ce qui tombe en panne. D'après mon expérience, les principales choses que j'ai eu à corriger après une mise à niveau sont

1. Modifications de certains éléments géniaux avec des modèles, tels que la syntaxe pour les clés étrangères suivantes.

2. Un petit ensemble de modèles a été modifié, notamment l'échappement automatique.

3. Tout ce qui dépend de la structure spécifique des composants internes de Django. Cela ne devrait pas poser de problème, sauf si vous modifiez de manière dynamique les composants internes de Django pour modifier leur comportement de la manière nécessaire / pratique pour votre projet.

Pour résumer, à moins que vous ne fassiez beaucoup de choses vraiment bizarres et / ou complexes, une simple mise à niveau devrait être relativement simple et ne nécessiter que quelques modifications.

Answer 2

Mise à niveau. Pour moi, c'était très simple: changez __ str __ () en __ unicode __ () , écrivez Basic admin.py , et c'est terminé. Commencez tout simplement à exécuter votre application sur 1.0, testez-la et, en cas d'erreur, utilisez la documentation de incompatible avec les versions antérieures. modifications pour voir comment résoudre le problème.

Answer 3

Mettez simplement votre application à niveau. Le passage de 0,96 à 1,0 était énorme, mais en ce qui concerne les modifications incompatibles en amont, je doute que votre application en possède même 10%.

J'étais dans le coffre avant Django 1.0, donc la transition a été longue, mais je n'avais encore changé que de nouveaux formulaires, newforms, newforms-admin, str () à unicode () et maxlength à max_length

La plupart des autres modifications concernaient de nouvelles fonctionnalités ou des réécritures de back-end ou des éléments qui, en tant que concepteurs de sites Web de base, ne s’approchent même pas.

Answer 4

Seuls les sites les plus simples sont faciles à mettre à niveau.

Si votre site est destiné à une partie du monde non ASCII , attendez-vous à une réelle douleur (lire: n'importe où en dehors des États-Unis et du Royaume-Uni). Le changement le plus douloureux dans Django a été de passer des octets octets à des objets unicode en interne. Vous devez maintenant rechercher tous les emplacements où vous utilisez des octets et les changer en unicode. Dans le pire des cas, c'est le rendu du modèle, vous ne saurez jamais que vous avez oublié de modifier une variable jusqu'à ce que vous obteniez UnicodeError.

Autre fait notable: les manipulateurs ( oldforms ) sont partis et vous n’avez pas d’autre moyen que de réécrire toutes les pièces avec des formulaires ( newforms ).

Si tel est votre cas et que votre projet dépasse 2 ou 3 applications, je serais plutôt réticent à mettre à niveau jusqu'à ce que ce soit vraiment nécessaire.

Answer 5

Nous avons procédé à une mise à niveau en plusieurs étapes et je suis assez satisfait de cela. L’application en question représentait environ 100 000 LdC et exécutait plusieurs fonctions de base avec de nombreuses interfaces avec les systèmes existants. Nous avons travaillé comme ça:

1. Mise à jour vers Django 0.97-post unicode fusionner. Résoudre tous les problèmes unicode
2. refactoriser l'application en applications réutilisables, ajouter des tests. Cela nous a laissé 40.000 Ldc dans l'application principale / Projet
3. Mettez à niveau vers la fusion django 0.97-post autoexcape. Corrigez l'échappement automatique dans les applications réutilisables créées dans 3. Corrigez ensuite les problèmes d'échappement automatique restants dans l'application mian.
4. Passez à la version 1.0. Ce qui restait était principalement de réparer les trucs de l’administrateur.

L'ensemble du processus a pris environ 6 mois lorsque nous avons géré une branche de production héritée sur nos serveurs tout en portant une autre branche à 1.0. Ce faisant, nous avons également ajouté des fonctionnalités à la branche de production.

La fusion finale a été beaucoup moins complexe que prévu et a pris environ une semaine pour la fusion, la révision, le test et la correction de 4 codeurs. Nous avons ensuite lancé le projet et, pendant environ une semaine, nous avons été piqués par des bugs inattendus.

Dans l’ensemble, je suis assez satisfait du résultat. Nous avons maintenant une base de code bien meilleure pour un développement ultérieur.