我想做的是能够为api用户提供为特定（并最终有多个）实体保存过滤器（例如/endpoint?id.in=123,456）的功能。
要执行实际的过滤器，我使用的是弹簧数据JPA规范（带有jhipster的Criteria DTO），它的工作原理很吸引人。 但是，要保留实际的Specification对象或CriteriaDTO，将是一项大任务（可能很麻烦）。
我的想法是创建一个通用的表结构（在postgres中），以支持我的过滤要求，并且足够通用以支持所有实体。然后使用该对象构造CriteriaDTO并将其传递给实体的服务 （如果需要，我可以发布我对表结构的想法）
在走这条路之前，我想从社区中获得见解，这里有更好的解决方案吗？
看起来这是常见的要求，可以有特定的模式
答案 0 :(得分：1)
但是，要保留实际的Specification对象或 CriteriaDTO，将是一项大任务（可能很麻烦）。
你为什么这么说？我不熟悉jhipster CriteriaDTO的工作原理，但是我知道如何创建规格。
为了创建规范，您需要从API端点获得的搜索条件。它可以是序列化的json对象，查询字符串参数，post参数或其他任何内容。
如果要为用户保存搜索条件，建议将其作为json（文本）字段存储在数据库中。因此，下一次用户想要使用相同的保存过滤器过滤数据时，只需获取存储的json，反序列化并将其提供给Specification（无需序列化Specification对象，只需序列化所使用的参数即可）为他的创作）。
我相信您的实现方式也是可行的，但是实现起来比较困难，我看不到任何好处，除了您可以查询过滤器参数（例如：查找最常用的过滤器） ）。