[infinispan-dev] some thoughts on mutual dependencies in Query/Search

[Sanne Grinovero]

+1
My initial thought was to implement Serializable and have a test for
it, but in practice just a subset of fields are needed across the
wire.

2011/6/30 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On Jun 30, 2011, at 11:50 AM, Sanne Grinovero wrote:
>>>> Clearly the Externalizer solution is highly coupled to the specific
>>>> version of Search, so that might become another issue in maintaining
>>>> them aligned, and this is not the appropriate class to be bound to a
>>>> "serialization contract", but is also the recommended way according to
>>>> Infinispan's spirit (compared to make it Serializable).
>>>
>>> why is it the recommended way. We're not putting HSQueryImpl in the grid are we? What's the need behind serialization?
>>
>> Yes we are sending it across the cluster, as it contains all the state
>> for the Query (both original definition and in-flight progress) and
>> then carries over the partial state to the next node to properly
>> iterate on the results. What concerns me most is the need to be
>> tightly coupled to this very internal class, as it also happens to be
>> the core of Search and will likely be affected by changes across
>> versions.
>> We'll see in a second phase if we can instead extract the needed state
>> and re-create it remotely from it: we might need to add more accessors
>> to the HSQuery interface but at least we'll have an interface coupling
>> instead of a binary-format coupling.
>
> Worse case, we do expose a HSQuery contract for hydratation / dehydratation so that an externalizer has a clear contract.