id fields with alternate names forced to Long

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

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.

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).

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.