title: Order of GORM cascaded saves depending on field names?
body: <p>I have the following arrangement of classes:</p>
  
  <pre><code>class A {
      static belongsTo = [c: C]
      B b
  }
  
  class B {
      static belongsTo = [c: C]
  }
  
  
  class C {
      static hasMany = [bbs: B, aas: A]
  }
  </code></pre>
  
  <p>If I now create instances of these classes...</p>
  
  <pre><code>B b = new B()
  A a = new A()
  a.b = b
  
  C c = new C()
  c.addToBbs(b)
  c.addToAas(a)
  </code></pre>
  
  <p>... and try to save c...</p>
  
  <pre><code>c.save()
  </code></pre>
  
  <p>... I get an <code>org.hibernate.TransientObjectException Message object references an unsaved transient instance - save the transient instance before flushing: B</code>.</p>
  
  <p>What I think GORM does is first to cascade the save to <code>c.aas</code> and then it stumbles over the instance <code>a.b</code> which is not saved yet. Therefore the exception.</p>
  
  <p>Now <strong>the trick</strong>: If I renamed the <code>aas</code> property of <code>C</code> to <code>xxs</code>, it works:</p>
  
  <pre><code>class C {
      static hasMany = [bbs: B, xxs: A]
  }
  </code></pre>
  
  <p><code>b</code> gets saved first, then <code>a</code>. GORM seems to cascade the saves in lexicographic order of the fields (first <code>bbs</code>, then <code>xxs</code>)!</p>
  
  <p><strong>How can I control the sequence GORM uses for the save cascading</strong> (except renaming the fields, which seems very brittle to me)?</p>