Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-RC1
    • Fix Version/s: 2.2-RC2
    • Component/s: Persistence
    • Labels:
      None
    • Environment:
      Lion,JDK 6

      Description

      the original url: http://grails.1312388.n4.nabble.com/DetachedCriteria-s-association-query-td3989063.html

      I have some domains which association reference are more than 2,for example:

      Class A { 
          B b 
      } 
      
      Class B{ 
          C c 
      } 
      
      Class C { 
          String name 
      } 
      

      When i use the detachedCriteria like this:

      new DetachedCriteria(A).build { 
          b { 
              c { 
                      eq('name','test') 
              } 
          } 
      } 
      

      There will throw such exception:
      message: could not resolve property: c of: A

      >> 639 | doCall in grails.gorm.DetachedCriteria$_list_closure2

      • - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        867 doCall in grails.gorm.DetachedCriteria$_withPopulatedQuery_closure9
        540 doCall . . . . . . . in org.grails.datastore.gorm.GormStaticApi$_withDatastoreSession_closure18
        301 execute in org.grails.datastore.mapping.core.DatastoreUtils
        34 execute . . . . . . in org.grails.datastore.gorm.AbstractDatastoreApi
        539 withDatastoreSession in org.grails.datastore.gorm.GormStaticApi
        850 withPopulatedQuery . in grails.gorm.DetachedCriteria

        Activity

        Hide
        Eli Israel added a comment -

        I'm getting this same error in 2.0.3. Here's a routine that looks to me like it should work, but I get the same exception described above. "could not resolve property 'user' of 'StatusUpdate'"

        The 'user' property belongs to the UpdateStream object references by the association "streams"

        def Collection<StatusUpdate> getUpdates(String streamName, DetachedCriteria crit, Map params = [:]) {
        crit = crit.build {
        streams {
        and {
        eq 'name', streamName
        user {
        inList 'externalID', this.socialAccounts.collect

        { it.externalID }

        }
        }
        }
        }

        crit.list(params)
        }

        Show
        Eli Israel added a comment - I'm getting this same error in 2.0.3. Here's a routine that looks to me like it should work, but I get the same exception described above. "could not resolve property 'user' of 'StatusUpdate'" The 'user' property belongs to the UpdateStream object references by the association "streams" def Collection<StatusUpdate> getUpdates(String streamName, DetachedCriteria crit, Map params = [:] ) { crit = crit.build { streams { and { eq 'name', streamName user { inList 'externalID', this.socialAccounts.collect { it.externalID } } } } } crit.list(params) }
        Hide
        Eli Israel added a comment -

        Fix in 2.2? This seems like a major bug without a decent workaround. If the fix is moving from being in the next "hot fix" to something two minor releases out, can we see why? Is there a dependency? This seems puzzling.

        Show
        Eli Israel added a comment - Fix in 2.2? This seems like a major bug without a decent workaround. If the fix is moving from being in the next "hot fix" to something two minor releases out, can we see why? Is there a dependency? This seems puzzling.
        Hide
        Aaron Long added a comment -

        I believe this bug has a few other variations which are much worse. In the example given, if you try to use more than one nested association, it will fail outright. However, if you just reference one association and then provide criteria inside it using the eq() method, it will do the join and ignore the criteria, returning incorrect results.

        Also, if you use the new Groovy-like syntax and try to reference more than one property deep, it will again create incorrect SQL and ignore the criteria. So, doing something like:

        Person(name: String) -> Face(type: String) -> Nose
        
        Nose.findAll {
            face.type == 'FAT' // this works
        }
        
        Nose.findAll {
            face.person.name == 'Jon' // this criteria is ignored
        }
        

        In the latter example, the join to Person never occurs and the query has a strange 1=1 at the end as if it had no criteria. I'm attaching a test app that includes a few of these examples as tests.

        Show
        Aaron Long added a comment - I believe this bug has a few other variations which are much worse. In the example given, if you try to use more than one nested association, it will fail outright. However, if you just reference one association and then provide criteria inside it using the eq() method, it will do the join and ignore the criteria, returning incorrect results. Also, if you use the new Groovy-like syntax and try to reference more than one property deep, it will again create incorrect SQL and ignore the criteria. So, doing something like: Person(name: String ) -> Face(type: String ) -> Nose Nose.findAll { face.type == 'FAT' // this works } Nose.findAll { face.person.name == 'Jon' // this criteria is ignored } In the latter example, the join to Person never occurs and the query has a strange 1=1 at the end as if it had no criteria. I'm attaching a test app that includes a few of these examples as tests.
        Hide
        Aaron Long added a comment -

        I actually consolidated all of my issues into one ticket and set of tests, GRAILS-9280.

        Show
        Aaron Long added a comment - I actually consolidated all of my issues into one ticket and set of tests, GRAILS-9280 .
        Hide
        sathish hariharan added a comment -

        Does anyone have a good workaround for this?

        Show
        sathish hariharan added a comment - Does anyone have a good workaround for this?

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            Ford Guo
          • Votes:
            4 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Last Reviewed:

              Development