> So ,when the stored fields are fetched from the
"DocumentService" the version number also is sent?
Yes.
You're probably wondering how we manage the older versions of an
object (aka id + version) in the DocService. We'd probably
delete the object as it's deleted from the index?
I use the word "
> 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).
So ,when the stored fields are fetched from the "DocumentService" the
version number also is sent?
As Grant mentioned , it would be nice
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 upd
the point is that the search will be done on committed docs and the
stored fields will show uncommitted data.how 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 en
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 dedicat
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 r
