lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Rutherglen <>
Subject Re: Solr document server/component
Date Tue, 11 Aug 2009 17:15:28 GMT
The ids would be stored in Solr, when a query is executed the
ids would be looked up from the DocumentService interface which
underneath would obtain the document data (aka stored fields).
Solr would then return the results combining the two, and
present the stored fields as it does today.

For updating something similar would occur, where the stored
fields are shuffled off to the DocumentService update method.

> how are we going to deal with this mismatch?

This is why we'd want to use optimistic concurrency, meaning
versions of ids encoded in the documents (which would also be
stored in the index ala GData).

2009/8/11 Noble Paul നോബിള്‍  नोब्ळ् <>:
> the point is that the search will be done on committed docs and the
> stored fields will show uncommitted are we going to deal with
> this mismatch?
> On Tue, Aug 11, 2009 at 6:50 AM, Grant Ingersoll<> wrote:
>> On Aug 10, 2009, at 7:30 PM, Jason Rutherglen wrote:
>>> It would be useful to enable a Solr document server (running
>>> Cassandra, HBase, or Voldemort) to be transparently integrated
>>> into a Solr search cluster. Meaning if I do a document update,
>>> Solr underneath sends the document data to the dedicated
>>> document server cluster. When performing a query, the results
>>> would automatically include documents from the document servers.
>>> This would fairly seamlessly separate the stored fields from the
>>> indexed fields. Has there been work along these lines yet?
>> I don't think any work has been done on it, but you are correct.  I'd add in
>> memcached and even, gasp, a DB, as well...  Of course, the more important
>> thing is the interface.
> --
> -----------------------------------------------------
> Noble Paul | Principal Engineer| AOL |

View raw message