Я получил несколько хороших ответов из списка рассылки Grails, и в заключении поделился комментарием Дэвида. смотрите тему здесь
Пара соответствующих ответов:
От Томаса Линя:
Я бы посоветовал заглянуть в Гаелика, если вы действительно хотите построить
проект на App Engine. Он построен с нуля с приложением
Двигатель как целевой двигатель, поэтому он может обойти проблемы, как долго
время загрузки из-за Spring и Hibernate. Недавно представленный плагин
механизм гарантирует, что ваши приложения Gaelyk могут быть расширены в
способ гарантированно работать на GAE.
У Gaelyk есть свой собственный DSL персистентности сущности, который немного
чище, что абстракции JPA / JDO поверх App Engine.
В настоящее время я вижу много исключений HardDeadlineExceeded с приложением
Двигатель и Грааль. Он просто не предназначен для работы с Spring
прямо сейчас. Надеюсь, это улучшится с более поздними выпусками
Groovy, Grails и партнерство Spring / Google для GAE для
бизнес, но я бы не подумал, что Grails на производстве GAE готов.
Даже с Gaelyk есть сообщения о низкой производительности. Так представь
трудности, которые возникают с гораздо большим стеком Grails.
App-engine поставляется с собственной реализацией пользователя / безопасности.
Система управления на основе учетных записей GMail. Если вы просто хотите предоставить
реализация администратора / не-администратора, это поддерживается в
Конфигурация appengine. Не могу комментировать Широ.
Имейте в виду, что одним из основных ограничений App Engine является
невозможность записи файла, поэтому даже базовая загрузка файлов в Spring
становится проблематичным, так как механизм по умолчанию пишет во временный
файл. Я полагаю, что большинство плагинов не будет работать из
коробка, не копаясь в их код и не меняя его.
Я думаю, что самая большая проблема здесь - это отсутствие поддержки нативного JDBC. JPA
не так хорошо поддерживается, как обычный JDBC GORM, такие как именованные запросы
вероятно, не будет работать из коробки без дооснащения. если ты
хотите использовать последние и лучшие части Grails, это может быть
Стоит рассмотреть и другие хостинговые решения.
От Аарона Эйшайда
1.Плагин GAE и плагины JPA-GORM вместе не обеспечивают всех возможностей GORM. Хотя вы должны получить основы, такие как .save (), .delete () и, возможно, .list (), динамические искатели и т. Д. Будут отсутствовать (по крайней мере, на данный момент). Я мог бы быть далеко отсюда, но я думаю, что большинство / все функции, зависящие от Hibernate, отсутствуют или заменены чем-то другим (поскольку он опирается на SQL под капотом, а GAE в настоящее время не имеет базы данных на основе SQL ...), например, любой Критерии строителей не идут. Мне неясно, сколько точечного сверления вы можете сделать на объектах. Например, не уверен, что вы могли бы сделать что-то вроде:
def b = новая книга ()
def stores = b.authors.publishers.bookstores
Я мог бы использовать несколько указателей, как использовать JPA в классах доменов. Я уверен, что есть хорошая информация, но я просто еще не нашел ее.
неуверенный
Плагины Grails, которые включают в себя классы домена или манипулируют текущими классами домена, неизбежно будут иметь проблемы, так как вы должны конструировать классы домена по-другому, чтобы хорошо играть с JPA, что необходимо, поскольку Googles Datastore не совсем похож на реляционный DB. С другой стороны. вы можете использовать встроенную систему безопасности Google, поэтому вам не обязательно нужны плагины, такие как Acegi или Shiro.
Это, вероятно, сводится к различным уровням GORM, которые вы можете использовать в контроллерах и сервисах, а также к различным способам определения классов домена. Некоторый рефакторинг кажется неизбежным, если JPA не играет так же хорошо с SQL DB, как с Googles Datastore. Если JPA может двигаться таким образом, то передача должна быть легкой, но с помощью JPA-GORM вы отказываетесь от некоторых вещей, которые вы, вероятно, хотели бы получить, если бы не получали выгоды из-за того, что находитесь на GAE.
Хочется услышать, что говорят другие,
Aaron