solrj:如何存储和检索List<POJO>通过索引中的多值字段
我的用例是一个包含在线媒体标题的索引.数据的提供者将类别列表与每个标题相关联.我正在使用 SolrJ 通过带注释的 POJO 类填充索引
My use case is an index which holds titles of online media. The provider of the data associates a list of categories with each title. I am using SolrJ to populate the index via an annotated POJO class
例如
@Field("title")
private String title;
@Field("categories")
private List<Category> categoryList;
关联的 POJO 是
public class Category {
private Long id;
private String name;
...
}
我的问题分为两部分:
a) 这可以通过 SolrJ 实现吗 - 文档仅包含使用字符串列表的 @Field 示例，因此我假设序列化/编组仅支持简单类型?
a) is this possible via SolrJ - the docs only contain an example of @Field using a List of String, so I assume the serialization/marshalling only supports simple types ?
b) 我将如何设置架构来保存它.我有一个天真的假设，我只需要设置multiValued=true 在必填字段 &一切都会变魔术.
b) how would I set up the schema to hold this. I have a naive assumption I just need to set multiValued=true on the required field & it will all work by magic.
我刚刚开始实施此功能，因此我们将不胜感激.
I'm just starting to implement this so any response would be highly appreciated.
推荐答案
答案如你所想:
a) 你只有简单的类型可用.因此，您将拥有一个相同类型的列表，例如细绳.关键是你不能在 lucene 文档中表示复杂的类型，所以你也不会反序列化它们.
a) You have only simple types available. So you will have a List of the same type e.g. String. The point is you cant represent complex types inside the lucene document so you wont deserialize them as well.
b) 问题是您正在尝试在文档存储"中表示关系思维.这可能只会在一定程度上起作用.如果您想在 lucene 文档中表示类别，只需使用字符串即可，也不必存储 id.
b) The problem is what you are trying is to represent relational thinking in a "document store". That will probably work only to a certain point. If you want to represent categories inside a lucene document just use the string it is not necessary to store a id as well.
同时存储 id 的唯一一点是:如果您想抛开搜索，请在 RDBMS 上进行查找.如果你想这样做，你需要确保 id 和类别名称是软链接的.这不适用于每个 1:n 关系.(每一个 n 相关表只包含必填字段的 1:n 关系都是可能的.如果您有一个可选字段，您需要尽可能在该字段中放置类似填充的空常量).
The only point to store an id as well is: if you want to do aside the search a lookup on a RDBMS. If you want to do this you need to make sure that the id and the category name is softlinked. This is not working for every 1:n relation. (Every 1:n relation where the n related table consists only of required fields is possible. If you have an optional field you need to put something like a filling emptyconstant in the field if possible).
但是，如果这些 1:n 关系不是稀疏的，那么实际上如果您保持将字段添加到文档的顺序，那么它实际上是可能的.因此，如果您不对列表进行排序，则可能可以表示具有类别关系的情况.
However if these 1:n relations are not sparse its possible actually if you maintain the order in which you add fields to the document. So the case with the category relation can be probably represented if you dont sort the lists.
如果你用位置 0...n 的值实例化它，你可以实现一个返回这个 Category 的方法.因此，解决方案是，如果您想要第一个类别，它将位于与该类别相关的每个列表的位置 0.
You may implement a method which returns this Category if you instantiate it with the values at position 0...n. So the solution would be if you want to have the first category it will be at position 0 of every list related to this category.
相关文章