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

[Emmanuel Bernard]

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.