[
https://issues.apache.org/jira/browse/LUCENE-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904010#comment-13904010
]
Greg Visotski commented on LUCENE-5000:
---------------------------------------
Hi Karl, I picked up your patch and have been testing it with Lucene 4.3.1. It
works perfectly, and I'd love to see it committed. Thank you!
> Query serialization using ObjectInput/OutputStream
> --------------------------------------------------
>
> Key: LUCENE-5000
> URL: https://issues.apache.org/jira/browse/LUCENE-5000
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/search
> Affects Versions: 4.3
> Reporter: Karl Wettin
> Priority: Trivial
> Attachments: LuceneQuerySerializer.java,
> TestLuceneQuerySerializer.java
>
>
> Reads and writes queries on ObjectInput/OutputStream.
> No support for ConstantScoreQuery (no serialization for Filter) nor
> PayloadNearQuery and PayloadTermQuery (no serialization for PayloadFunction).
> I might have missed to implement support for some core Queries. Currently
> supported are: TermQuery, BooleanQuery, WildcardQuery, PhraseQuery,
> MultiPhraseQuery, FuzzyQuery, RegexpQuery, TermRangeQuery, NumericRangeQuery,
> DisjunctionMaxQuery, MatchAllDocsQuery, SpanTermQuery,
> SpanMultiTermQueryWrapper, SpanNearQuery, SpanNotQuery, SpanOrQuery,
> FieldMaskingSpanQuery, SpanFirstQuery, SpanPositionRangeQuery,
> SpanPayloadCheckQuery and SpanNearPayloadCheckQuery.
> Users are allowed to implement and register strategies for their own queries.
> This will not allow you to serialize any object graph with aggregated Query
> instances e.g. Map<String, Query>, that would require a new implementation of
> ObjectOutputStream (one could base that on the GPL2 code from OpenJDK) or
> instrument the existing implementations to handle Query in private
> writeObjectA and similar methods.
> There's a bit of reflection glue in this code in order to read private fields
> in query implementation. Not too happy about that, but not much to do unless
> one is to expose a bunch of new getters in all those classes.
> The class is places in o.a.l.search in order to access package visible fields
> without getters. If moving to another package this would have to be handled
> using reflection as with above mentioned private fields.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
