Объяснение принадлежности к Grails

Из документации Grails принадлежит, в чем польза

   class Book {
    static belongsTo = Author
}

Как каскадные операции влияют на Book, когда операции CRUD выполняются на Author?

РЕДАКТИРОВАТЬ:

Спасибо за ответы, может я не правильно сформулировал вопрос. Я хотел бы знать разницу между

 static belongsTo [author:Author]

vs

 static belongsTo = Author

person Sanjeev    schedule 06.02.2014    source источник
comment
Что касается вашего редактирования, они ничем не отличаются (и на самом деле первым должно быть static belongsTo = [ author: Author ]). Они будут иметь тот же эффект. Первая форма просто позволяет указать имя свойства.   -  person Charles Wood    schedule 03.10.2014


Ответы (5)


belongsTo полезен, если вам нужна ссылка на объект-владелец. В этом случае вполне вероятно, что Author имеет много Book. Но, возможно, вы используете объект книги и хотите упомянуть Author этого экземпляра книги. Это хороший способ получить его.

Что касается CRUD, удаление или обновление книги ничего не сделает с Author, но удаление Author приведет к удалению Book. Если вы не добавите belongsTo, то не будет каскадных сохранений/обновлений/удалений, вам придется делать это вручную.

Пример:

def a = new Author(name: 'J.K. Rawling')
a.addToBooks(new Book(title: 'Harry Potter 1'))
a.addToBooks(new Book(title: 'Harry Potter 2'))
a.save()   // Saves author and book instances

a.delete() // Author and both books are deleted

Изменить:

ОП обновил свой вопрос, и я, честно говоря, не уверен, каким будет ответ. Надеюсь, Берт Беквит скоро появится! Хороший вопрос, ОП.

person grantmcconnaughey    schedule 06.02.2014
comment
Должно быть J. K. Rowling :)) - person August; 19.09.2017

Оба способа предлагают каскадные эффекты одинаковым образом. Единственное их отличие состоит в том, что в первом случае у вас будет ссылка на автора в объекте Book, а во втором — нет. То есть:

Вы можете сказать Book b = new Book(); b.author во втором случае.

person Alexander Suraphel    schedule 09.07.2014

В дополнение к Grantmc:

ownTo практически отмечает встроенный тип отношения между ними, поэтому все операции автоматически каскадируются при его использовании.

Без принадлежности вам нужно вручную определить каскады (если вы хотите вообще какие-либо каскады для вашего отношения)

person sola    schedule 06.02.2014
comment
какие каскады в данном случае? только для удаления скажем книг при удалении автора? Если вы никогда не удаляете, поможет ли BelongsTo? - person John Little; 18.10.2018

Это кажется мне запутанным и требует дополнительных усилий, поскольку я могу добиться того же результата в отношениях, просто используя один hasMany и игнорируя belongsTo, но вам нужно сделать, скажем, переменную класса Author в Book домене/классе

class Author {
    static hasMany = [books: Book]
}

class Book {
    Author author  //can have only one Instance to be saved at a time
}

Но причина, по которой вы используете belongsTo, заключается в том, что вы заставляете отношения следовать по пути от Author до Book при вставке данных, сохраняя идеальный способ управления отношениями с использованием belongsTo. Если вы не укажете его как переменную класса или не используете belongsto, Grails вообще не поймет двустороннюю связь.

person Daniel Adenew    schedule 06.02.2014
comment
Лично я до сих пор не вижу разницы между: class Book {Author author} и class Book { static existsTo = Author}. Оба указывают, что у книги есть автор (следовательно, она должна принадлежать по определению). Я всегда использую первый, я никогда не использовал belogsTo и не замечал никаких проблем (я никогда не удаляю данные, только отмечаю как удаленные) - person John Little; 18.10.2018

Как сказано в документе, это то же самое, что и ownTo = [author:Author], чем ownTo = Autor, оба создадут свойство с именем author, ссылающееся на «отцовский» объект.

Салудос

person Gerardo Manuel López Fernández    schedule 31.10.2014