Hi all, It seems to me that the "commit" logic in the Solr updateRequestHandler (or wherever the logic is actually located) conflates two different semantics. One semantic is what you need to do to make the index process perform well. The other semantic is guaranteed atomicity of document reception by Solr.
In particular, it would be nice to be able to post documents in such a way that you can guarantee that the document is permanently in Solr's queue, safe in the event of a Solr restart, etc., even if the document has not yet been "committed". This issue came up in the LCF talk that I gave, and I initially thought that separating the two kinds of events would necessarily be an LCF change, but the more I thought about it the more I realized that other Solr indexing clients may also benefit from such a separation. Does anyone agree? Where should this logic properly live? Thanks, Karl
