Порядок каскадирования GORM сохраняется в зависимости от имен полей? В самом деле?

У меня есть следующее расположение классов:

class A {
    static belongsTo = [c: C]
    B b
}

class B {
    static belongsTo = [c: C]
}


class C {
    static hasMany = [bbs: B, aas: A]
}

Если я теперь создаю экземпляры этих классов...

B b = new B()
A a = new A()
a.b = b

C c = new C()
c.addToBbs(b)
c.addToAas(a)

... и попытайтесь сохранить c...

c.save()

... Я получаю org.hibernate.TransientObjectException Message object references an unsaved transient instance - save the transient instance before flushing: B.

Я думаю, что GORM делает сначала каскад сохранения в c.aas, а затем он натыкается на экземпляр a.b, который еще не сохранен. Поэтому исключение.

Теперь трюк: если я переименовал свойство aas в C в xxs, он будет работать:

class C {
    static hasMany = [bbs: B, xxs: A]
}

b сначала сохраняется, затем a. Кажется, что GORM каскадирует сохранение в лексикографическом порядке полей (сначала bbs, затем xxs)!

Как я могу контролировать последовательность использования GORM для каскадного сохранения (кроме переименования полей, которые мне кажутся очень хрупкими)?

Ответы

B b = new B().save()  
A a = new A(b: b)  // b should already be persisted as A doesn't `belongsTo` B
C c = new C()
c.addToBbs(b)
c.addToAas(a)
c.save()

class A {
    static belongsTo = [c: C]
    B b

    static mapping = {
        b cascade: 'save'
    }
}

B b = new B()
A a = new A()
a.b = b

C c = new C()
c.save()
c.addToBbs(b)
c.addToAas(a)