title: How does solr work with data split into different services and therefore not synchronously available?
body: <p>take for instance an ecommerce store with catalog and price data in different web services. Now, we know that solr does not allow partial updates to a document field(<a href="https://issues.apache.org/jira/browse/SOLR-139" rel="nofollow">JIRA bug</a>), so how do you index these two services  ?
  I had three possibilities, but I'm not sure which one is correct:</p>
  
  <ol>
  <li>Partial update - not possible</li>
  <li><p>Solr join - have price and catalog in separate index and join them <strong>in solr</strong>. You cant join them in your client side code, without screwing up pagination and facet counts. I dont know if this is possible in pre-solr 4.0</p></li>
  <li><p>have some sort of intermediate indexing service, which composes an entire document based on the results from both these services and sends this for indexing. however there are two problems with this approach:</p>
  
  <p>3.1 You can still compose documents partially, and then when the document is complete, you can set a flag indicating that this is a complete document. However, to do this each time a document has to be indexed, it has to first check whether the document exists in the index, edit it and push it back. So, big performance hit.
  3.2 Your intermediate service checks whether a particular id is available from all services - if not silently drops it and hopes that when it appears in the other service, the first service will already be populated. This is OK, but it means that an item is not available in search until all fields are available (not desirable always - if u dont have price, you can simply set it to out-of-stock and still have it available)</p></li>
  </ol>
  
  <p>Of all these methods, only #3.2 looks viable to me - does anyone know how you do this kind of thing with DIH? Because now, you have two different entry points (2 different web services) into indexing and each has to check the other</p>