@JsonIgnore is stopping me from getting and posting foreign keys, but program crashes without it

[Nathan Milota]

I've been using the @JsonIgnore because when I get a list of all users, there is a foreign key of company to match the company of the user, and when I do a get request, without @JsonIgnore, it creates an infinite loop that crashes the program.

However, when doing a post request, I cannot post the company to the user with the @JsonIgnore in there, because it comes up null.  

Is there a solution to this?   I cannot find it.

[Nathan Milota]

I solved part of the problem by including

@JsonProperty(access = JsonProperty.Access.WRITE_ONLY)

However, I still need to be able to read the company, because when trying to get values from it in Angular, it is coming back undefined because it can't read it.   I don't know what to do.

[Ron McLeod]

What is the relationship between Users and Companies?

[Nathan Milota]

The User class has a ManyToOne and the Company class has a OneToMany.   I showed the classes in my other thread related to Angular and Typescript that's causing an undefined error.

[Ron McLeod]

Assuming that a Company that the User will be a member of already exists, wouldn't you just want to provide an identifier for the Company, and not all of the company's attributes when creating a new User?

Also, why does Company have a collection of the Users?  That is going to create a kind of circular reference which is probably the source of your infinite loop.

[Nathan Milota]

What are you saying?   Ditch the entire OneToMany and ManyToOne relationship, and just give a company number to a user?

[Nathan Milota]

I just don't get it, if the OneToMany relationship always behaves this way, why would anyone ever use it?

[Stephan van Hulst]

You've run into the classic trap of using the same class to model your database entry and your service response.

Don't do this.

It may seem like you're duplicating code, but the responsibilities of your web service layer and your persistence layer should be kept completely separate.

[Stephan van Hulst]

Nathan Milota wrote:I just don't get it, if the OneToMany relationship always behaves this way, why would anyone ever use it?

That's not what Ron is saying. He's saying you shouldn't have a circular reference in your requests/responses.

The solution, as I posted above, is to create one set of classes for your requests/responses, a different set of classes for your database, and one more set of classes for your business layer.

This may seem like overkill. Trust me, it's not.

[Nathan Milota]

I don't understand what that means.   Do you have an example?

[Stephan van Hulst]

Business layer:

package com.example.foo;

public final class User {

  private final String id;

  private final String userName;

  private final Company company;

  public User(String id, String userName, Company company) {
    this.id       = requireThat("id",       id,       is(nonEmptyStrippedString()));
    this.userName = requireThat("userName", userName, is(nonEmptyStrippedString()));
    this.company  = requireThat("company",  company,  is(notNullValue()));
  }

  public String id() {
    return id;
  }

  public String userName() {
    return userName;
  }

  public Company company() {
    return company;
  }
}

Persistence layer:

package com.example.foo.persistence;

@Entity
public final class UserEntity {

  @Id
  @GeneratedValue
  @Column(name = "id")
  private long id;

  @Column(name = "userName")
  private String userName;

  @ManyToOne
  @JoinColumn(name = "companyId", referencedColumnName = "id")
  private CompanyEntity company;

  UserEntity() {}

  public UserEntity(String userName, CompanyEntity company) {
    this.userName = requireThat("userName", userName, is(nonEmptyStrippedString()));
    this.company  = requireThat("company",  company,  is(notNullValue()));
  }

  public UserEntity(User user, CompanyEntity company) {
    requireThat("user",    user,    is(notNullValue()));
    requireThat("company", company, is(notNullValue()));

    this.id       = Long.parseLong(user.id());
    this.userName = user.userName();
    this.company  = company;
  }

  public String getId() {
    return Long.toString(id);
  }

  public String getUserName() {
    return userName;
  }

  public CompanyEntity getCompany() {
    return company;
  }
}

Web service layer:

package com.example.foo.api

public final class UserData {

  private final String userName;

  private final String companyName;

  @JsonCreator
  public UserData(
    @JsonProperty("userName")    String userName
    @JsonProperty("companyName") String companyName
  ) {
    this.userName    = userName;
    this.companyName = companyName;
  }

  public UserData(User user) {
    requireThat("user", user, is(notNullValue()));

    this.userName    = user.userName();
    this.companyName = user.company().name();
  }

  @JsonProperty("userName")
  public String getUserName() {
    return userName;
  }

  @JsonProperty("companyName")
  public String getCompanyName() {
    return companyName;
  }
}

The User class from the business layer has no idea about the web service layer or the persistence layer. It is the primary class that models a user, and if you want to perform logic on a user, you will want to do it with this class. It may contain circular references: A User references a Company and the referenced Company may refer back to the User.

The UserEntity class from the persistence layer is very similar to the User class from the business layer. The main reason it's separate is because it's not easy to enforce class invariants on JPA entities. Therefore you only use it when you want to persist your user to the database, or when you want to retrieve it from the database. Immediately convert it to a User object, and don't perform logic on it directly.

The UserData class from the web service layer is a flattened object model that you can use to (de)serialize requests and responses to the web service. There are two major differences with the other two classes: First, it doesn't contain a reference to a company instance, because you should not have circular references in your requests and responses. Secondly, it doesn't contain an ID that was generated by the DBMS. You must not expose such IDs to the outside world.