2010-07-16 2 views
2

Я застрял в этой проблеме. Код выглядит хорошо для меня (очевидно, я что-то не хватает. Вопрос заключается в том, что это такое?)Гравильное каскадное поведение

У меня есть класс проекта

def class project{ 
    ... 
    Manager manager 
} 

Это Личность и класс менеджер определения

def class Person{ 
    String firstName 
    String lastName 
} 

def class Manager extends Person{ 
    static hasMany = [ projects: Project] 

} 

Взаимоотношения просты - у Проекта есть один менеджер, а у менеджера есть много проектов. Насколько мне известно, в отношениях «один ко многим» сохраняются каскады, потому что они двунаправленные «один ко многим». Но когда я делаю это

Project project = new Project() 
Manager mgr = new Manager(...) 
project.manager = mgr 
project.save() 

Я получаю следующее сообщение об ошибке Вызванные: org.hibernate.TransientObjectException: объект ссылается на несохраненный переходный экземпляре - сохранить переходный экземпляр перед промывкой: менеджер

и когда я делаю это

Project project = new Project() 
Manager mgr = new Manager(...) 
project.manager = mgr 
project?.manager.save() 
project.save() 

Это работает просто отлично. Но я думаю, что проект? .manger.save() не требуется!

ответ

2

Быстрое решение состоит в том, чтобы сохранить менеджера перед сохранением проекта.

У вас также нет доступа к настройке. Ознакомьтесь с главой 5 документации по гравиям.

http://grails.org/doc/latest/

«В случае двунаправленного один-ко-многим, где многие сторона не определяет belongsTo то стратегия каскада установлен в положение„SAVE-UPDATE“для одной стороны и„NONE“ для многих сторон ».

Так что, если я получаю это правильно, вы можете позвонить сэкономить на MGR (одна сторона), но не экономить на стороне проекта (чтобы каскадные работать)

В случае двунаправленного одно- to-many, где многие стороны определяют принадлежность. Тогда для каскадной стратегии установлено значение «ALL» для одной стороны и «NONE» для многих сторон.

Вы также захотите ознакомиться с разделом 5.5.2.9, где вы можете указать настраиваемое каскадное поведение.

+0

Спасибо за ваш ответ. Да, менеджер экономии сначала делает трюк. Но ownTo не помогает. Каков правильный способ сделать это i) Удалить менеджера менеджера и просто иметь static принадлежитTo = [менеджер: менеджер] или статический принадлежитTo = Менеджер ii) Сохранение менеджера диспетчера и наличие статического атрибута Too = [manager: Manager] или static принадлежит To = Manager. BTW, я пробовал оба, и он не работает. На данный момент быстрое исправление работает – Paras

+0

hmm Я думаю, что правильный путь - сохранить одну сторону. «В случае двунаправленного« один ко многим », где многие стороны определяют принадлежность, тогда для каскадной стратегии устанавливается« ALL »для одной стороны и« NONE »для многих сторон». Даже с принадлежностью к каскаду NONE для многих сторон. Сохранение многих сторон сначала не будет работать, если одна сторона еще не настойчива. Я думаю, что это имеет смысл, потому что обычно вы добавляете менеджера в систему, сохраняете его, а затем добавляете проекты. Хотя я мог видеть случай, когда вы будете делать то же самое. – hvgotcodes

 Смежные вопросы

  • Нет связанных вопросов^_^