Grails
  1. Grails
  2. GRAILS-9375

id fields with alternate names forced to Long

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.4
    • Fix Version/s: None
    • Component/s: Data binding
    • Labels:
    • Environment:
      Mac OS 10.8.1, java "1.6.0_33"

      Description

      If a domain class has an id field with a name other than 'id', which is mapped appropriately in the mapping block, the Class.get(id) method is converting the id to a Long before submitting to Hibernate, which is causing an error, like

      Class org.hibernate.TypeMismatchException
      Message Provided id of the wrong type for class tmmweb.StorageFile.
      Expected: class java.lang.Integer, got class java.lang.Long`

      This appears to be related to some older bugs with other types for an id field named 'id', but may not have been fixed when the id field has a different name.

        Activity

        Hide
        Lari Hotari added a comment -

        I don't think this is a bug. Question answered on Stackoverflow http://stackoverflow.com/a/12242791/166062

        Show
        Lari Hotari added a comment - I don't think this is a bug. Question answered on Stackoverflow http://stackoverflow.com/a/12242791/166062
        Hide
        Peter N. Steinmetz added a comment -

        Had a look at the comments, though still believe this is a bug.

        The documentation for Grails in many places implies that one can change the name of a field with a 'id' element in the mapping block, and the Hibernate docs certainly imply that Hibernate will respect such and use introspection on the named field to determine a type. This is consistent with it's report that it is expecting an Integer, and with the fact that changing that field to a 'Long' fixes the problem.

        The 'get' method which is being dynamically added to the Class appears to be supplying a Long to the call to Hibernate, even when the field is an Integer and it is mapped to an Integer in the id element of the mapping block.

        It would seem this get method shouldn't cast the object to a Long, or rather should cast it to the type which Hibernate is expecting for that particular field.

        Show
        Peter N. Steinmetz added a comment - Had a look at the comments, though still believe this is a bug. The documentation for Grails in many places implies that one can change the name of a field with a 'id' element in the mapping block, and the Hibernate docs certainly imply that Hibernate will respect such and use introspection on the named field to determine a type. This is consistent with it's report that it is expecting an Integer, and with the fact that changing that field to a 'Long' fixes the problem. The 'get' method which is being dynamically added to the Class appears to be supplying a Long to the call to Hibernate, even when the field is an Integer and it is mapped to an Integer in the id element of the mapping block. It would seem this get method shouldn't cast the object to a Long, or rather should cast it to the type which Hibernate is expecting for that particular field.
        Hide
        Lari Hotari added a comment -

        Yes there must be a bug in using an alternative property name for id. I suggest to use the workaround to give the id file an alias with the property name you like, for example:

        // if you want to add an alias for "id"
        static transients = ['fileId']
        
        public Integer getFileId() { id }
        

        You can always map the id to any column name in the data base with the "column" attribute.

        I tested that "Integer id" works without any problems in this case. You should add the property definition to the class in this case:

        Integer id
        

        Simplified example (based on your Stackoverflow question):

        class StorageFile {
        static mapping = {
          id column:'file_id'
        }
        
        Integer id 
        String content
        
        static transients = ['fileId']
        public Integer getFileId() { id }
        }
        

        Scaffolding doesn't seem to support an id with some other name than "id". I don't really see the case of why would you really want to change it if you can always alias it.
        We could fix this problem by adjusting the documentation (removing support for "name" in id).

        Show
        Lari Hotari added a comment - Yes there must be a bug in using an alternative property name for id. I suggest to use the workaround to give the id file an alias with the property name you like, for example: // if you want to add an alias for "id" static transients = ['fileId'] public Integer getFileId() { id } You can always map the id to any column name in the data base with the "column" attribute. I tested that "Integer id" works without any problems in this case. You should add the property definition to the class in this case: Integer id Simplified example (based on your Stackoverflow question): class StorageFile { static mapping = { id column:'file_id' } Integer id String content static transients = ['fileId'] public Integer getFileId() { id } } Scaffolding doesn't seem to support an id with some other name than "id". I don't really see the case of why would you really want to change it if you can always alias it. We could fix this problem by adjusting the documentation (removing support for "name" in id).
        Hide
        Peter N. Steinmetz added a comment -

        Yes, I would think the preferable solution is really to fix the bug in Grails. But lacking that, removing it from the documentation would at least save people from spending >4 hours trying to figure out why it doesn't work.

        Show
        Peter N. Steinmetz added a comment - Yes, I would think the preferable solution is really to fix the bug in Grails. But lacking that, removing it from the documentation would at least save people from spending >4 hours trying to figure out why it doesn't work.

          People

          • Assignee:
            Unassigned
            Reporter:
            Peter N. Steinmetz
          • Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development