Domain subclass with embedded property causing MissingPropertyException for "save"

Please attach an example that reproduces the problem.

I am getting the same problem. It also includes the delete method. I've got it narrowed down to 2 test cases that have to run one after the other in order to reproduce the problem. I will work on an example, too.

I did this demo application which shows the problem:

class Face {
Integer width
Integer heigth
Nose nose
}
class Nose {
Integer length
static belongsTo = [face:Face]
}

I want to update an existing Nose instance. First, I load the face which owns the nose:
def face = Face.get(faceId)
I get the corresponding nose to update its length :
def nose = face.nose
nose.length = 10

Now, I want to save the nose:
nose.save(flush:true).

In Grails 1.1 : OK, no problem, nose is saved.
In Grails 1.1.1 : KO: I get this error : groovy.lang.MissingPropertyException: No such property: save for class: Nose.
Doing a face.save() works correctly (cascading to nose which is correctly saved (both in Grails 1.1 and 1.1.1)

I seems that Nose is not recognized as a Domain class.

I have this issue too. Only seems to happen when the Child record (Nose in the above example) is retrieved off its owner. It is still possible to create and then save the Child without error, and also retrieve the child directly (i.e. Nose.get(1)) and save it ok, as long as its parent association is not involved.

As per Burt Beckwith's post, he managed to find a workaround which I haven't tested yet, but I'd like to post it here so that people would know about it.

----snipped from threaded post http://www.nabble.com/save()-method-on-domain-class-seen-as-property-td23659161.html#a23663421 -----

I played with this a bit and it seems like a Groovy bug to me - there doesn't seem to be a sensible Grails-specific reason why it thinks save() is a property invocation and not a method invocation.

I found a workaround though. HibernateGrailsPlugin (using HibernatePluginSupport) wires up the GORM methods and most are lazily initialized to reduce startup time. The save() call is failing to invoke the MissingMethodException that triggers this lazy initialization but I found that if I call DomainClass.count() or list() that it does wire up the methods and save() works after that.

So a hackish fix (until this is fixed in an upcoming release) would be to put count() calls in BootStrap for the problematic domain classes, or even for all of them, e.g.

class BootStrap {
  def grailsApplication
  def init = { servletContext ->
    for (dc in grailsApplication) {
      dc.clazz.count()
    }
  }
}

For what it's worth, I first hit this problem when I switched from dbCreate = "create-drop" to dbCreate = "update"... switch back and the problem goes away.

Now I have to have some code similar to what Chris Chen commented above.

I think the severity of this should be bumped to blocker. On about all my classes calling save() does not work anymore since 1.1.1. I can reproduce this all the time, if you need a sample to debug just shout.

We have the same problem here. Thanks for the hints.

Domainclass.count() in BootStrap.groovy works for us too.

I also get this problem. However it is only on domain objects from a plugin. Also it is also only on Tomcat 6.0. When I deploy the app for the first time I get the problem. If I then stop and restart the server it goes away. Not good !!

In case it is useful to anyone, here is a variation of Chris Chen's workaround that I got to work:

import org.codehaus.groovy.grails.commons.ApplicationHolder

class BootStrap
{
    def init = { servletContext ->
        // workaround for GRAILS-4580
        ApplicationHolder.application.domainClasses.each { dc ->
            dc.clazz.count()
        }
    }
}

The work around throws a new type of exception.

I have the same problem as described above, but within the bootstrap. I' m trying to fill up the database with a little default data and when i switched from dbCreate: "create-drop" to "update" the trouble started.

So what I do create a few parents and try to save them and the exception appears. If I read well everyone here got the exception on child instances.

After applying the described workarounds I now get the following error:

org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: Parent