Grails
  1. Grails
  2. GRAILS-1799

Relations Mapping (Foreign keys) with GORM DSL don't work

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0-RC1
    • Fix Version/s: 1.0-RC2
    • Component/s: Persistence
    • Labels:
      None
    • Environment:
      windows, microsoft sql server

      Description

      In my tables the foreign key to the Customer is the column 'CustID' .
      Grails expect a column named customer_id and I tried to change this with the following Code:

      class User {
      static belongsTo = [customer:Customer]

      static mapping = {
      table 'CustomerContacts'
      version false
      columns

      { id (column:'ContactID') email (column: 'Email') customer (column: 'CustID', type:'int') }

      Grails uses the changed id and email column but ignores the customer mapping.

      Hibernate:
      select
      top 1 this_.ContactID as ContactID0_0_,
      this_.version as version0_0_,
      this_.admin as admin0_0_,
      this_.change_password_secret_code as change4_0_0_,
      this_.customer_id as customer5_0_0_,
      this_.Email as Email0_0_,
      this_.password as password0_0_,
      this_.username as username0_0_
      from
      user this_
      where
      this_.username=?

        Activity

        Hide
        Matt DeHoust added a comment -

        This is also easy to see if you set codehaus.groovy.grails.orm.hibernate="debug,stdout" in Config.groovy and then do grails run-app.

        In my case, I have the following domain classes mapped to a legacy schema.

        class Item {
        String description
        //...
        static mapping = {
        table 'INVMST'
        version false
        id generator:'assigned'
        columns

        { id column:'INUMBR' description column:'IDESCR' //... }

        }
        }

        class MarkChange {
        String reasonCode
        Integer quantity
        Item item
        //...

        static mapping = {
        columns

        { item column:'ITEM_NUMBER' }

        }
        }

        The log shows the following when I run the app.

        [2156] cfg.GrailsDomainBinder [GrailsDomainBinder] Mapping Grails domain class: MarkChange -> mark_change
        ...
        [2156] cfg.GrailsDomainBinder [GrailsDomainBinder] Binding persistent property [item]
        [2156] cfg.GrailsDomainBinder [GrailsDomainBinder] Binding property [item] as OneToOne
        [2156] cfg.GrailsDomainBinder [GrailsDomainBinder] bound property [item] to column name [item_id] in table [mark_change]

        Instead of binding to column name item_number as configured, the item property is bound to item_id, which is the name produced by the default naming convention.

        I have spent a little time perusing the GrailsDomainBinder code and its test cases. I am not yet sure how to write a test to prove this is doing the wrong thing.

        Show
        Matt DeHoust added a comment - This is also easy to see if you set codehaus.groovy.grails.orm.hibernate="debug,stdout" in Config.groovy and then do grails run-app. In my case, I have the following domain classes mapped to a legacy schema. class Item { String description //... static mapping = { table 'INVMST' version false id generator:'assigned' columns { id column:'INUMBR' description column:'IDESCR' //... } } } class MarkChange { String reasonCode Integer quantity Item item //... static mapping = { columns { item column:'ITEM_NUMBER' } } } The log shows the following when I run the app. [2156] cfg.GrailsDomainBinder [GrailsDomainBinder] Mapping Grails domain class: MarkChange -> mark_change ... [2156] cfg.GrailsDomainBinder [GrailsDomainBinder] Binding persistent property [item] [2156] cfg.GrailsDomainBinder [GrailsDomainBinder] Binding property [item] as OneToOne [2156] cfg.GrailsDomainBinder [GrailsDomainBinder] bound property [item] to column name [item_id] in table [mark_change] Instead of binding to column name item_number as configured, the item property is bound to item_id, which is the name produced by the default naming convention. I have spent a little time perusing the GrailsDomainBinder code and its test cases. I am not yet sure how to write a test to prove this is doing the wrong thing.
        Hide
        Matt DeHoust added a comment -

        This patch adds a test method to GrailsDomainBinderTests that, I believe, exposes the bug.

        Show
        Matt DeHoust added a comment - This patch adds a test method to GrailsDomainBinderTests that, I believe, exposes the bug.
        Hide
        Matt DeHoust added a comment -

        There was an error in the original patch. This patch has a valid test that exposes the bug.

        Show
        Matt DeHoust added a comment - There was an error in the original patch. This patch has a valid test that exposes the bug.
        Hide
        Matt DeHoust added a comment -

        This patch fixes the issue (at least for single-column foreign keys where the column name has been explicitly mapped). The test case is also included.

        Show
        Matt DeHoust added a comment - This patch fixes the issue (at least for single-column foreign keys where the column name has been explicitly mapped). The test case is also included.
        Hide
        Lee Butts added a comment - - edited

        I've applied Matt's patch - thanks Matt.

        cheers

        Lee

        Show
        Lee Butts added a comment - - edited I've applied Matt's patch - thanks Matt. cheers Lee
        Hide
        Raghu added a comment -

        It seems that this bug is not fixed yet in grails 1.0.4. If there is a workaround please let me know.

        Show
        Raghu added a comment - It seems that this bug is not fixed yet in grails 1.0.4. If there is a workaround please let me know.

          People

          • Assignee:
            Graeme Rocher
            Reporter:
            Marco Stahl
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development