我想要做的是能够为api用户提供为特定(最终是多个)实体保存过滤器(例如/endpoint?id.in=123,456)的能力。
为了执行实际的过滤,我使用了spring data JPA规范(带有jhipster的标准DTO),效果非常好。然而,要持久化实际的规范对象或CriteriaDTO,将是一项很大(可能很混乱)的任务。
我的想法是创建一个通用的表结构(在postgres中),它将支持我的过滤需求,并且足够通用,以支持所有实体。然后使用该对象构造CriteriaDTO并将其传递给实体的服务(如果需要,我可以发布我对表结构的想法)
在我走上这条路之前,我想从社区中获得见解,这里有更好的解决方案吗?
看起来这是一个非常常见的需求,可以有一个特定的模式
发布于 2018-10-25 03:47:27
然而,要持久化实际的
对象或CriteriaDTO,将是一项很大(而且可能很混乱)的任务。
你为什么要这么说?我不熟悉jhipsters CriteriaDTO
是如何工作的,但我知道规范是如何创建的。
为了创建规范,您需要可能从API端点获得的搜索条件。它可以是序列化的json对象、查询字符串参数、post参数等等。
如果您想保存用户的搜索条件,我建议将其作为json (文本)字段存储在数据库中。因此,下次用户想要使用相同的过滤器过滤数据时,只需获取存储的json,对其进行反序列化并将其提供给规范(不需要序列化Specification
对象,只需将用于创建的参数)。
我相信你的实现方式也是可能的,但它更难实现,我看不到任何好处,除了你可以查询过滤器参数(例如:查找哪个是最常用的过滤器)。
https://stackoverflow.com/questions/52970739
复制相似问题