谷歌应用程序引擎上的Grails

bsr*_*bsr 12 grails google-app-engine

grails和google app引擎部署的当前状态是什么.我是app引擎的新手,但值得探索.一些特定的qns

  1. 最新的插件,用户评价高,有任何限制吗?或者它与所有gorm功能无缝协作
  2. Grails应用程序的启动时间是否有任何问题.现实世界中的情况如何?(典型的小型和大型应用)
  3. 其他grails插件怎么样(如shiro,joda time,nimble等).我猜他们不会打得好.因此,直接使用这些库是更好的选择
  4. 如果决定放弃goole-app作为部署选项,那么切换到正常环境是多么容易.JPA支持确保与其他传统DB的兼容性?

不确定还有什么是主要问题..可能,这是一个很好的讨论的基础.
谢谢.

bsr*_*bsr 2

我从 grails 邮件列表中得到了一些好的回应,结论与 David 的评论一致。请参阅此处的线程

几个相关的回应:

来自托马斯·林:

如果您确实想在 App Engine 上构建一个项目,我建议您研究一下 Gaelyk。它是从头开始构建的,以 App Engine 作为目标引擎,因此它可以绕过 Spring 和 Hibernate 导致的加载时间长等问题。新引入的插件机制保证您的 Gaelyk 应用程序可以以保证在 GAE 上运行的方式进行扩展。

Gaelyk 有自己的本机实体持久性 DSL,它比 App Engine 之上的 JPA/JDO 抽象更清晰一些。

目前,我在 App Engine 和 Grails 中看到许多 HardDeadlineExceeded 异常。它现在的设计还不能很好地与 Spring 配合使用。希望这会随着 Groovy、Grails 的后续版本以及针对 GAE 的 Spring/Google 商业合作伙伴关系而得到改善,但我不认为 Grails 在 GAE 生产上做好了准备。

即使使用 Gaelyk,也有性能缓慢的报告。想象一下更大的 Grails 堆栈所带来的困难。

该应用程序引擎附带了它自己的基于 GMail 帐户的用户/安全管理系统的实现。如果您只想提供管理/非管理实现,appengine 配置中支持此功能。无法对士郎发表评论。

请注意,App Engine 的主要限制之一是无法写入文件,因此即使在 Spring 中上传基本文件也会出现问题,因为默认机制会写入临时文件。我想如果不深入研究代码并进行更改,大多数插件都无法开箱即用。

我认为这里最大的问题是缺乏对原生 JDBC 的支持。JPA 的支持不如普通 JDBC GORM 那样好,如果不进行改造,命名查询之类的东西可能无法开箱即用。如果您想使用 Grails 的最新、最好的部分,可能值得考虑其他托管解决方案。

来自亚伦·艾沙伊德

1.GAE插件和JPA-GORM插件相结合并不能无缝地为您提供所有GORM功能。尽管您应该了解 .save()、.delete() 等基础知识,也许还有 .list() ,但动态查找器等将被淘汰(至少目前如此)。我可能离这里很远,但我认为大多数/所有 Hibernate 相关功能都已淘汰或被其他功能取代(因为它在幕后依赖于 SQL 并且 GAE 目前没有基于 SQL 的数据库...)所以例如任何标准制定者是不行的。我不清楚你可以在物体上进行多少点钻孔。例如,不确定您是否可以执行以下操作:

def b = new Book() def Stores = b.authors.publishers.bookstores

我可以使用一些指针的地方是如何在域类中使用 JPA。我确信那里有很好的信息,但我只是还没有找到。

  1. 不确定

  2. 包含域类或操作当前域类的 grails 插件必然会出现问题,因为您必须以不同的方式构建域类才能与 JPA 很好地配合,这是必要的,因为 Google 数据存储不太像关系数据库。另一方面。您可以使用 Google 内置的安全性,因此不一定需要 Acegi 或 Shiro 等插件。

  3. 这可能归结为您可以在控制器和服务中使用的 GORM 的不同级别以及定义域类的不同方式。一些重构似乎是不可避免的,除非 JPA 与 SQL DB 的配合与与 Google 数据存储的配合一样好。如果 JPA 可以像这样移动,那么转移应该很容易,但是通过使用 JPA-GORM,如果您由于使用 GAE 而没有从中受益,您可能会放弃一些您可能想要的东西。

渴望听听别人怎么说,

亚伦