I really feel like an annotation would make the most sense. How likely is it
that the object could not be annotated or the serializer for the object is not
tightly coupled with the object? Having to map objects to serializers
externally then becomes a lot more complicated to keep consistent.
Sent from my iPhone
> On Jul 20, 2017, at 10:38 AM, Dan Smith <dsm...@pivotal.io> wrote:
>
> 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
>>>
>>>
>>
