groovy
  1. groovy
  2. GROOVY-3316

Find a solution to the collection coping problem involving findAll, grep etc. that causes Hibernate lazy loading to break

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.6-rc-2
    • Fix Version/s: 1.6-rc-3
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      2

      Description

      See http://www.nabble.com/findAll-and-Lazy-loaded-Hibernate-JPA-collections-broken-in-Groovy--1.6-td21682669.html

      This issue is critical, we either need to revert to the original behavior or find a solution that supports the new behavior whilst not breaking specialized collection types like those used in Hibernate

        Activity

        Hide
        Guillaume Laforge added a comment - - edited

        The grails app attached to this issue should exhibit the Hibernate problem: GRAILS-3831

        Show
        Guillaume Laforge added a comment - - edited The grails app attached to this issue should exhibit the Hibernate problem: GRAILS-3831
        Hide
        Guillaume Laforge added a comment -

        With the latest changes in GROOVY_1_6_0 branch, the sample Grails application from GRAILS-3831 now pass the tests successfully.

        Show
        Guillaume Laforge added a comment - With the latest changes in GROOVY_1_6_0 branch, the sample Grails application from GRAILS-3831 now pass the tests successfully.
        Hide
        Jim White added a comment -

        How is it that the change is made on the 1.6.0 branch first (and so far only)? It should go to trunk first, or at least GROOVY_1_6_X.

        Show
        Jim White added a comment - How is it that the change is made on the 1.6.0 branch first (and so far only)? It should go to trunk first, or at least GROOVY_1_6_X.
        Hide
        blackdrag blackdrag added a comment -

        because it seems as a reasonable short term fix. But for the other branches we can look into this issue a bit more. Paul wanted to think about this a bit more for example. The applied patch is more or less a roll back. As we discussed on the list I considered a roll back if no solution was found till today. Maybe cloning this issue would be good... with fix targets for 1.6.1 and 1.7

        Show
        blackdrag blackdrag added a comment - because it seems as a reasonable short term fix. But for the other branches we can look into this issue a bit more. Paul wanted to think about this a bit more for example. The applied patch is more or less a roll back. As we discussed on the list I considered a roll back if no solution was found till today. Maybe cloning this issue would be good... with fix targets for 1.6.1 and 1.7
        Hide
        Paul King added a comment -

        I am thinking though that we should align all of the codebases to be what we have in 1.6.0 and then explore modifications from there. Otherwise I know I will find discussions confusing.

        Show
        Paul King added a comment - I am thinking though that we should align all of the codebases to be what we have in 1.6.0 and then explore modifications from there. Otherwise I know I will find discussions confusing.

          People

          • Assignee:
            blackdrag blackdrag
            Reporter:
            Graeme Rocher
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: