GAE 可移植性架构选型及 django-nonrel 简介
浏览数：23 /
时间：2015年06月08日
http://www.allbuttonspressed.com/projects/django-nonrel
http://www.allbuttonspressed.com/
最近在考虑做GAE应用，可移植性是个麻烦事，我们看中GAE更易维护，更低成本，但如果应用发展到GAE不能满足需求时，我们希望移植到非GAE server上的时候，就会遇到麻烦。所以，可移植性是GAE应用的关键。
因为GAE使用自己的datastore技术，所以GAE app移植的关键在ORM的移植。
其实这个麻烦也同样存在于RDBMS想NOSQL的移植。
我想起了ruby-conf-china 2010时，老庄的演讲，一个ActiveRecord的Middleware（实在不知道怎么描述，哪位擅于表达的指正一下），可以让Rails的特性毫无改变的运行于一个nosql的db之上。
Ruby圈最流行的web框架时Rails，ORM是Rails的ActiveRecord。 Python圈自然是Django了，ORM则是Django ORM。
说了这么多，主角要登场了。那就是 django-nonrel， 顾名思义，就是 django none relationship，非关系型的django。django-nonrel只是一层adapter。若要使其工作，还需要特定的backend。对于GAE，我们需要下载 djangoappengine,——the App Engine backend for Django-nonrel。如果是mongodb，我们需要下载django-mongodb-engine: the MongoDB backend for Django-nonrel。
如果这个项目进展顺利的话，pythoner的nosql体验就会更加享受了，appengine开发，也同样会更加接近非GAE环境。
但在下对于django-nonrel有点小小的意见，这个项目更应该作为一个django的patch发布。但作者却选择了将所有django代码塞在了项目中，直接在django代码上操刀，这无疑会给开发者带来困扰。
http://www.allbuttonspressed.com/
最近在考虑做GAE应用，可移植性是个麻烦事，我们看中GAE更易维护，更低成本，但如果应用发展到GAE不能满足需求时，我们希望移植到非GAE server上的时候，就会遇到麻烦。所以，可移植性是GAE应用的关键。
因为GAE使用自己的datastore技术，所以GAE app移植的关键在ORM的移植。
其实这个麻烦也同样存在于RDBMS想NOSQL的移植。
我想起了ruby-conf-china 2010时，老庄的演讲，一个ActiveRecord的Middleware（实在不知道怎么描述，哪位擅于表达的指正一下），可以让Rails的特性毫无改变的运行于一个nosql的db之上。
Ruby圈最流行的web框架时Rails，ORM是Rails的ActiveRecord。 Python圈自然是Django了，ORM则是Django ORM。
说了这么多，主角要登场了。那就是 django-nonrel， 顾名思义，就是 django none relationship，非关系型的django。django-nonrel只是一层adapter。若要使其工作，还需要特定的backend。对于GAE，我们需要下载 djangoappengine,——the App Engine backend for Django-nonrel。如果是mongodb，我们需要下载django-mongodb-engine: the MongoDB backend for Django-nonrel。
如果这个项目进展顺利的话，pythoner的nosql体验就会更加享受了，appengine开发，也同样会更加接近非GAE环境。
但在下对于django-nonrel有点小小的意见，这个项目更应该作为一个django的patch发布。但作者却选择了将所有django代码塞在了项目中，直接在django代码上操刀，这无疑会给开发者带来困扰。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
