This proposal doesn't really talk about XML or gfsh support.
The XML should probably just be a nested xml element, like this. It should
have the same support for declarables that other callbacks in the xml do.
<lucene:index name="index1">
<lucene:serializer> com.mycompany.MySerializer </lucene:serializer>
</lucene:index>
The gfsh command to create an index should also accept a serializer, like
this
create lucene index --serializer=com.mycompany.MySerializer
If there are no objections I'll update the proposal.
-Dan
On Tue, Jul 18, 2017 at 10:38 AM, Dan Smith <dsm...@pivotal.io> wrote:
> I think this LuceneSerializer API needs a slight tweak. In order to
> implement the proposed FlatFormatSerializer, the serializer needs access to
> the index configuration to see what fields the user wants to index. We
> should also pass the LuceneIndex to the serializer.
>
> public interface LuceneSerializer {
> Collection<Document> toDocuments(Object value, *LuceneIndex index*);
> }
>
> On Thu, Jul 13, 2017 at 2:19 PM, Dan Smith <dsm...@pivotal.io> wrote:
>
>> On Thu, Jul 13, 2017 at 11:26 AM, Jacob Barrett <jbarr...@pivotal.io>
>> wrote:
>>
>>> Collections are really tough in Lucene because you have to flatten the
>>> document. I struggled against it for some time on a project a few years ago
>>> and ultimately decided to index the relationships separately and then merge
>>> the results.
>>>
>>
>> Yeah, this is part of the motivation for providing the LuceneSerializer
>> API. We can provide a built in serializer that just flattens all nested
>> collections into a single field, but users could also write their own
>> implementation that converts the nested objects into separate lucene
>> documents and use some of query classes in org.apache.lucene.search.join if
>> they really need to.
>>
>> It's not part of the goal here, but I think this LuceneSerializer API
>> could also make it easier to do spatial indexing, because users could
>> create a serializer that converts their gemfire object into a Lucene
>> document with GeoPointFields.
>>
>> -Dan
>>
>>
>
