app-engine-patch 终于正式宣布死亡了：
New project announcement
app-engine-patch is dead. Join the Django non-relational project and follow the Django nonrel blog if you want to use Django’s ORM on App Engine and other NoSQL / non-relational databases. We’d also be grateful for any help.
当然开源项目的好处是它dead也好，开发者不再维护也好，只要你继续愿意用和维护总还可以继续的。 app engine patch里集成了一些不错的东西，用了一阵子下来，觉得其实我觉得它有价值的地方不在于把django的一些东西给patch能用了，而在于其包含的一些附件。app engine patch的一些弊病也是明显的，其实任何这类patch都存在类似的一些问题。
app-engine-patch的作者已经把精力转移到django non-relational project去了，不过我看了看自己认为并不太看好。 django nonrel实际上是对django的更大手脚的patch, 达到的好处是让应用代码和django本身更兼容，这样可能可以不需要修改就跑在django或GAE上。 然而问题在于这个目前能做到的兼容性随着django, GAE本身的不断发展，以及开发维护者的兴趣的变化，今后能保持到什么程度？ 这和过去app-engine-patch本身的目标其实是类似的，只不过途径不同而已。
app engine的一些本身native的设计，尤其是datastore的设计，既然是non-relational的，以non-relational的思想去设计其实更加有优势。django nonrel通过重新实现一个model来让代码看上去和relational的代码保持一致，我总觉得未必是件好事，相反我觉得过去的app engine patch的思路更有价值。
不过一旦专门支持app engine 的data store, 就出现了所谓的lock in could的问题，其实Amazon AWS, Windows Azure以及任何一种环境都有类似的问题。这也许正是任何cloud computing厂商所期望的效果。由于GAE本身是开源的，让GAE的应用脱离GAE并能高性能跑起来的可能是比较大的。 Amazon的AWS提供的比较底层，相对lock的效应不强，但是scalability基本得要自己来实现，和自己建数据中心比基本没有减少技术和架构上的成本，但在设备、网络、维护方面降低了成本。 Windows Azure的对用户的锁定是最多的，不过Azure的主要用户群可能本来也就不太会考虑LAMP的方案反正已经锁定MS技术了也就无所谓了。
