Игнорируйте некоторые поля для десериализации JSONB в Spring JPA

#java #spring #hibernate

Вопрос:

У меня есть модель Spring JPA

 @Entity
@Table(name = "projects")
@TypeDefs({ @TypeDef(name = "jsonb", typeClass = JsonBinaryType.class) })
public class Project implements Serializable {

  @Id
  private long id;


  @Column(name = "version_id")
  private Long version;

  @Column(name = "created_by")
  private String createdBy;

  @Column(name = "created_at")
  private LocalDateTime createdAt;

  @Column(name = "updated_by")
  private String updatedBy;

  @Column(name = "updated_at")
  private LocalDateTime updatedAt;

  @Column(name = "is_archived")
  private Boolean archived;

  private String commentsRoomId;

  private String workflowType;
  private String workflowId;

  @Type(type = "jsonb")
  @Column(columnDefinition = "jsonb")
  private Map<String, ProjectSection> sections;
 

Теперь данные в последнем свойстве являются свойством JSONB, которое должно игнорировать некоторые поля. так как его тоже не было бы в базе данных.

Теперь, когда я пытаюсь получить данные, я получаю следующую ошибку.

 The given Json object value: {s06=ProjectSection(version=1, enabled=true, type=milestones, values={}, visibility=null, sectionId=null, sectionSchema=null)
 

что говорит об этом после повторения json.

Теперь мой раздел выглядит так

 @NoArgsConstructor
@AllArgsConstructor
@Data
public class ProjectSection {

  @JsonProperty("version_id")
  private Long version;

  @JsonProperty("enabled")
  private Boolean enabled;

  @JsonProperty("type")
  private String type;

  @JsonProperty("values")
  private Map<String, ProjectField> values;

  @JsonProperty("visibility")
  private List<String> visibility;

  // Not Srtored in DB
  @JsonIgnore
  @Transient
  private String sectionId;

  @JsonIgnore
  @Transient
  private ProjectTemplate.SectionSchema sectionSchema;
 

Я думаю, может быть, из-за того, что он находится во вложенных полях JSONB transient , это не имеет смысла.
Как я должен убедиться, что эти значения игнорируются, когда он десериализуется из БД и загружается правильно.
Если я удалю эти дополнительные поля, это, кажется, сработает.

Ответ №1:

Почему бы вам не использовать некоторые картостроители ModelMapper или DozerMapper для обработки таких случаев.

Комментарии:

1. Мне действительно не нужно сопоставлять это с каким-либо техническим директором. Я получаю это при самом чтении, когда получаю данные из БД

2. Я понимаю, но слой картографа был бы полезен от любого слоя к любому слою. Когда-нибудь вам, возможно, потребуется исключить еще несколько столбцов. Вы не можете постоянно изменять свою аннотацию. Лучше выбрать картограф, который работает во всех случаях.

3. Я согласен, что картограф-лучшее решение, и я хотел бы добавить, что вам следует изучить представления сущностей Blaze-Persistence, которые даже повышают производительность, поскольку они доходят до уровня запроса и извлекают только то, что действительно необходимо: github.com/Blazebit/blaze-persistence#entity-view-usage

4. Я не согласен с использованием картографа без крайней необходимости. Ваши классы представляют ваши сущности. Аннотации можно использовать для определения того, как они должны быть представлены в сохраняемости, когда передаются в виде DTO, а классы могут даже содержать бизнес-логику и логику проверки. Наличие анемичной модели предметной области с логикой, разбросанной по остальной части кода, и требование всего в трех экземплярах просто кажется контрпродуктивным. Это очень быстро утомляет, становится намного проще создавать ошибки, и это добавляет еще больше движущихся частей, которые могут выйти из строя.

5. @G_H Не могли бы вы, пожалуйста, помочь мне с лучшей практикой и примером, чтобы понять, что вы пытаетесь донести. может быть, это фрагмент кода, так как ответ будет легко просмотреть и принять его.