You are right, we can always transmit the string form and re-parse on the other-end. Our problem is that we took this (serialization nature) for granted, and once something is deployed over a cluster, it would be difficult to do partial roll-outs in this case. But I guess there is no immediate remedy for this.
Since we all agree careful scrutiny is a good thing: ScoreDocComparator.sortValue(), according to its javadoc: "The object returned must implement the java.io.Serializable interface." This has implicit implications how a distributed system should be designed around lucene, in my case result merge. You cannot transmit Strings or any other representatives around, because you don't know what the Comparable instance is (when SortField.type is set to Custom). I am curious, how would distributed Solr handle this without resorting to Java serialization? A side note, do you think returning Comparable here is good api design, shouldn't it be some sub-interface that extends both Comparable and Serializable, instead of resorting to javadoc? Thanks -John On Wed, Dec 3, 2008 at 10:19 AM, Doug Cutting (JIRA) <[EMAIL PROTECTED]>wrote: > > [ > https://issues.apache.org/jira/browse/LUCENE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652882#action_12652882] > > Doug Cutting commented on LUCENE-1473: > -------------------------------------- > > > But, what's now being asked for (expected) with this issue is "long-term > persistence", which is really a very different beast and a much taller > order. > > That's the crux, alright. Does Lucene want to start adding cross-version > guarantees about the durability of its objects when serialized by Java > serialization. This is a hard problem. Systems like Thrift and > ProtocolBuffers offer support for this, but Java Serialiation itself doesn't > really provide much assistance. One can roll one's own serialization > compatibility story manually, as proposed by this patch, but that adds a > burden to the project. We'd need, for example, test cases that keep > serialized instances from past versions, so that we can be sure that patches > do not break this. > > The use case provided may not use RMI, but it is similar: it involves > transmitting Lucene objects over the wire between different versions of > Lucene. Since Java APIs, like Lucene, do not generally provide > cross-version compatibility, it would be safer to architect such a system so > that it controls the serialization of transmitted instances itself and can > thus guarantee their compatibility as the system is updated. Thus it would > develop its own representations for queries independent of Lucene's Query, > and map this to Lucene's Query. Is that not workable in this case? > > > > Implement Externalizable in main top level searcher classes > > ----------------------------------------------------------- > > > > Key: LUCENE-1473 > > URL: https://issues.apache.org/jira/browse/LUCENE-1473 > > Project: Lucene - Java > > Issue Type: Bug > > Components: Search > > Affects Versions: 2.4 > > Reporter: Jason Rutherglen > > Priority: Minor > > Attachments: LUCENE-1473.patch > > > > > > To maintain serialization compatibility between Lucene versions, major > classes can implement Externalizable. This will make Serialization faster > due to no reflection required and maintain backwards compatibility. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
