Announcement Announcement Module
No announcement yet.
Changing id field breaks generated functionality? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Changing id field breaks generated functionality?


    I have the classes "User", "Group" and "Authority". User is associated to Group through an intersection entity "UserGroup" and Group is associated with Authority through "GroupAuthority".

    User and Group have the default "id" field as the primary key. I did a generate-all for UserGroup and it's working perfectly fine.

    In "Authority", I changed the id field to make it "authority" as follows:
    	static mapping = {
    		id name:'authority', generator:'assigned'
    I did a generate-all for "GroupAuthority" but it did not work because the views were referencing the "id" field. So, I modified the views to replace "id" with the correct field name; i.e. "authority".

    Still, when I try to save, I get the error: not-null property references a null or transient value.

    I'm not sure why this is happening. When I look at the generated code for "UserGroup" I find that nothing special is being done. The "params" are bound to the object and then it's saved. It's not like the code is explicitly using the id to load the persistent User or Group objects and then associate them (I'm assuming it's done auto-magically somewhere).

    In my case, I'm doing the same thing but it's not working. Does this approach only work when the key field is called "id"?


  • #2
    I just came across this statement in the user guide.
    Grails will automatically detect the .id suffix on the request parameter.
    So, it seems that the magic word here is "id" and any other field used as a key is not recognized.

    I wonder if it would be possible to enhance this functionality.

    For example, using the same objects as the guide, currently if it finds the request parameter "", then it looks up the Author instance. If the id field is called "authorId", then it won't. Instead, would it possible to inspect the Author class to get which field is the id field?

    Would that have unwanted side effects?

    I just don't feel that it's appropriate to name the field which holds the authority code in my Authority class "id" and I also believe that this particular class should not have a surrogate key because it's considered meta-data and is completely controlled by the development team.


    • #3
      Scaffolding is heavily geared towards the conventions, which basically means an integer ID. Also, the data binding (where automatically binds an Author instance to the current object) may depend on that as well, although there is an identity() method if I remember correctly.

      I suggest you raise a JIRA issue so we can look into this.