Why is with a many-to-many the response data recursive...?

[Nico van de Kamp]

Hello,

I have a many-to-many relation defined like:

public class EmployeeModel implements Serializable {
@ManyToMany(targetEntity = Role.class, cascade = CascadeType.MERGE )
    private List<Role> roles;

    public List<Role> getRoles() {
        return roles;
    }

    public void setRoles(List<Role> roles) {
        this.roles = roles;
    }
    ....

}

My Role entity:

public class Role  {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String description;
    @ManyToMany(targetEntity = EmployeeModel.class, mappedBy = "roles", cascade = CascadeType.ALL)
    private List<EmployeeModel> employeeRoleModel;     /* commented out */

    /* Begin commented out */
    public List<EmployeeModel> getEmployeeRoleModel() {
        return employeeRoleModel;
    }

    public void setEmployeeRoleModel(List<EmployeeModel> employeeModel) {
        this.employeeRoleModel = employeeModel;
    }
    /* End commented out */
    ....

If I do a GET with Postman and the parts mentioned commented out are inactive, than I get in my opinion the right data for the response:

[
    {
        "id": 1,
        "employeeName": "Nicoa",
         .... here are other fields
        "roles": [
            {
                "id": 1,
                "name": "Admin",
                "description": "Administrator"
            },
            {
                "id": 3,
                "name": "Guest",
                "description": "Gast"
            }
        ]
    }
]

Technically I have find out were it comes from, if i activate the lines which I have mentioned "commented out", than it is getting recurence!!??
I have roles added to the employee that's good. But the GET is also returning the roles wiht the employee etc.
My Question: why is this made in this way? And when do I need this? I mean I can't imagine if you are working on an entity, that a response as shown here beneath would be used for the frontend, or...

{
        "id": 1,
        "employeeName": "Nicoa",
         .... here are other fields
        "roles": [
            {
                "id": 1,
                "name": "Admin",
                "description": "Administrator",
                "employeeRoleModel": [
                    {
                        "id": 1,
                        "employeeName": "Nicoa",
                        "employeeCode": "ECN0004",
                        "designation": "ZZZZZ",
                        "createdDateTime": "2021-08-24T14:13:13.039125",
                        "modifiedDateTime": "2021-08-24T14:13:13.039125",
                        "address": {
                            "id": 1,
                            "doorNumber": "37",
                            "street": "Laakse Laan",
                            "city": "Zutphen"
                        },
                        "department": {
                            "id": 1,
                            "deptName": "Nieuwegein"
                        },
                        "logging": [
                            {
                                "id": 2,
                                "title": "Dit is de titel van de 2e opmerking Nico",
                                "infotext": "Dit is de infotext van de 2e opmerking voor Auke"
                            },
                            {
                                "id": 1,
                                "title": "Dit is de titel - nieuw opmerking voor Nico",
                                "infotext": "Dit is de infotext van Auke"
                            }
                        ],
                        "unit": {
                            "id": 3,
                            "unitCode": "ZN",
                            "description": "Zuid Nederland"
                        },
                        "roles": [
                            1,
                            {
                                "id": 3,
                                "name": "Guest",
                                "description": "Gast",
                                "employeeRoleModel": [
                                    {
                                        "id": 1,
                                        "employeeName": "Nicoa",
                                        "employeeCode": "ECN0004",
                                        "designation": "ZZZZZ",
                                        "createdDateTime": "2021-08-24T14:13:13.039125",
                                        "modifiedDateTime": "2021-08-24T14:13:13.039125",
                                        "address": {
                                            "id": 1,
                                            "doorNumber": "37",
                                            "street": "Laakse Laan",
                                            "city": "Zutphen"
                                        },
                                        "department": {
                                            "id": 1,
                                            "deptName": "Nieuwegein"
                                        },
                                        "logging": [
                                            {
                                                "id": 2,
                                                "title": "Dit is de titel van de 2e opmerking Nico",
                                                "infotext": "Dit is de infotext van de 2e opmerking voor Auke"
                                            },
                                            {
                                                "id": 1,
                                                "title": "Dit is de titel - nieuw opmerking voor Nico",
                                                "infotext": "Dit is de infotext van Auke"
                                            }
                                        ],
                                        "unit": {
                                            "id": 3,
                                            "unitCode": "ZN",
                                            "description": "Zuid Nederland"
                                        },
                                        "roles": [
                                            1,
                                            3
                                        ]
                                    }
                                ]
                            }
                        ]
                    }
                ]
            },
            3
        ]
    }

[Rob Spoor]

1) When an EmployeeModel instance is serialized, all of its properties are included. One of those properties is roles. This is a List<Role>, and each element is serialized.
2) When these Role instances are serialized, all of their properties are included. One of those properties is employeeRoleModel. This is a List<EmployeeModel>, and each element is serialized.
3) See 1.

There are some ways to fix this. One is to create POJOs for your REST responses. You end up mostly duplicating your class, but you can easily leave out the things you don't want.
Another way to fix this is to mark the employeeRoleModel as ignored during serialization. How to do this depends on the serialization framework. For instance, for Jackson you'd use @JsonIgnore.

I prefer the first way, because

it allows me to create different POJOs for retrieving EmployeeModel instances with nested Role instances, or the other way around. If you ignore these in your entities, you can only have one of these options

it will ignore anything I don't want. That includes any properties added by the JPA framework (I remember TopLink adding its own properties)

[Nico van de Kamp]

Hello Rob,

Thanks. I don’t know if I understand you but do you mean by creating different POJO’s.
The Role class I have made and with commented out List<EmployeeModel> employeeModel, so that the employeeRoleModel properties are not included
And make another Role POJO for maintenance screen of Role, because Role need to be filled with reference data.

Is that what you mean?

[Rob Spoor]

With POJO (plain old Java object) i mean a simple object that has fields, getters and setters, but nothing JPA related.

To expose employees, you'd need two classes:
* EmployeeDto: contains all scalar properties (String, numeric, etc) from EmployeeModel, as well as a List<EmployeeRoleDto>
* EmployeeRoleDto: contains only scalar properties from Role; no property for EmployeeDto

If you need to expose roles with their employees, you can create similar classes RoleDto and RoleEmployeeDto, where RoleDto has a List<RoleEmployeeDto> and RoleEmployeeDto does not have any link to RoleDto.

[Nico van de Kamp]

Thanks Rob,

Again 'slowly' I think that I understand what I need todo:

There are some ways to fix this. One is to create POJOs for your REST responses. You end up mostly duplicating your class, but you can easily leave out the things you don't want.

I prefer the first way, because
it allows me to create different POJOs for retrieving EmployeeModel instances with nested Role instances, or the other way around. If you ignore these in your entities, you can only have one of these options
it will ignore anything I don't want. That includes any properties added by the JPA framework (I remember TopLink adding its own properties)

I was thinking why is it necessary to create new DTO POJOs? I'm satisfied by commented out the private List<EmployeeModel> employeeRoleModel in the Role Entity, there is no recurrence of data in the response, so it is good. But if I want to do something with the Roles POJOs, for instance maintenance CRUD, I'm getting in trouble or I need to define a new Role Entity or something like that if possible

Now I return for my REST responses the 'emloyeeModel', which I think have to replace by the new POJOs EmployeeModelDTO class instance. Here I define the EmployeeModelDto (which is than more or less duplicate with EmployeeModel), AND return the EmployeeModelDto as response to frontend(Postman), that is the most important thing to realize/understand.

Another way to fix this is to mark the employeeRoleModel as ignored during serialization. How to do this depends on the serialization framework. For instance, for Jackson you'd use @JsonIgnore.

I see code where they have more or less choosen for this solution.

I have the feeling of you're first approach is better because it is more flexible and is further independent what is happening in other entity's - loosely coupled.

[Rob Spoor]

Right. So all you need to do is:
* create the DTOs
* map entity instances to DTO instances
* return the DTO instance instead of the entity

One thing to keep in mind is that either the roles list in the EmpoyeeModel entity needs to be eager, or you need to retrieve its contents while the transaction is still active. Otherwise, you'll have a detached entity and you'll get an exception when you try to access the roles. You can perform the mapping inside the transaction, or ensure the roles are fetched. A trick is to call getRoles().size(); calling getRoles() alone doesn't force a trip to the database, retrieving its size (or any element) does.