Migration de l'application Django sur Google App Moteur?

Il y a quelques éléments que vous ne pouvez pas faire sur le moteur d'applications que vous pouvez faire sur votre propre serveur comme le téléchargement de fichiers. Sur le moteur d'application, vous devez un peu de télécharger et stocker le magasin de données pouvant causer quelques problèmes.

Autre que cela devrait être bien de la partie de présentation. Il existe un certain nombre d'autres petites choses qui sont meilleures sur votre propre serveur dédié, mais je pense que beaucoup de ces choses seront dans le moteur d'application

Fondamentalement, vous modifierez la classe de base du modèle de données et certaines API si vous les utilisez (PIL, URLLIB2, etc.).

Si votre objectif est App-moteur, j'utilise l'aide du moteur d'application http: //code.google.com/appengine/articles/appengine_helper_for_django.html . Il peut l'exécuter sur votre serveur avec un dB basé sur un fichier, puis le pousser à l'app-moteur sans changement.

La plupart (tout?) de Django est disponible à GAE, votre tâche principale est donc d'éviter de baser vos conceptions autour d'une dépendance sur quoi que ce soit de Django ou des bibliothèques standard Python qui n'est pas disponible sur GAE.

Vous avez identifié la différence flagrante, qui est la base de données, donc je suppose que vous êtes en plus de cela. Une autre différence est la liaison des comptes Google et donc que si vous le souhaitez, vous pouvez effectuer une bonne quantité de contrôle d'accès via le fichier App.YAML plutôt que dans le code. Vous n'avez pas à utiliser de cela, cependant, donc si vous n'envisageez pas la commutation sur des comptes Google lorsque vous passez à GAE, aucun problème.

Je pense que les différences entre les bibliothèques standard peuvent principalement être déduites du fait que GAE n'a pas d'E / S et aucune bibliothèques accélérée C, sauf indication explicite, et mon expérience jusqu'à présent est que des choses que je m'attendais à être là. , ont été là. Je ne sais pas Django et je ne l'ai pas utilisé sur Gae (à part des modèles), donc je ne peux pas commenter cela.

Personnellement, je ne cible probablement pas la lampe (où p = django) avec l'intention de migrer à Gae plus tard. Je développerais pour les deux ensemble et essayer de vous assurer que si possible, les différences sont conservées au sommet (configuration) et au fond même (modèle de données). La version GAE ne doit pas nécessairement être parfaite, tant que vous savez comment le rendre parfait si vous en avez besoin.

Il n'est pas garanti que cela soit plus rapide que d'écrire, puis de le porter, mais je suppose que c'est normalement. Le moyen le plus simple de repérer toutes les différences est d'exécuter le code plutôt que de ne rien manquer de ne rien manquer dans les docs GAE, vous sauverrez donc probablement des erreurs qui doivent être impatientes. Le SDK Python est une approximation assez bonne du véritable moteur de l'application, de sorte que toutes ou la plupart de vos tests peuvent être exécutés localement la plupart du temps.

Bien sûr, si vous décidez finalement de ne pas le port, vous avez effectué des travaux inutiles, vous devez donc penser à la probabilité de cela et que vous envisagiez de considérer le développement du GAE comme un gaspillage de votre temps s'il est pas nécessaire.

On dirait que vous avez une prise de conscience de la principale limitation dans la construction / la migration de votre application - que Appengine ne prend pas en charge l'orme de Django.

Gardez à l'esprit que cela n'affecte pas simplement le code que vous vous écrivez - cela limite également votre capacité à utiliser beaucoup de code Django existant. Qui inclut d'autres applications (telles que les applications administratives intégrées et autorités) et des fonctionnalités à base d'orm, telles que Vues génériques .