#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 Не могли бы вы, пожалуйста, помочь мне с лучшей практикой и примером, чтобы понять, что вы пытаетесь донести. может быть, это фрагмент кода, так как ответ будет легко просмотреть и принять его.