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

>> 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.