: 2. Can anyone think of any reasons why this might not be a good idea? (I : *just* started considering this)
: 3. I read http://wiki.apache.org/solr/SolrCaching , but I think the : whole cache discarding and warming wouldn't be needed if what I store in : memcached is: StringRepresentationOfQuery > DocSet or DocList . Hm, I : see QueryResultKey class now. Then maybe I'd store QueryResultKey -> : DocSet or DocList in the memcached cache. Is this a correct? The nice thing about the internal caching is that because it's internal, it can be autowarmed, and it can store things that only make sense as part of the internal API (ie: big OpenBitSet based DocSets that rely on the IndexReader for getting the real field contents) when you start talking about caching the data outside of Solr, I don't think the "internal" SolrCache APIs make as much sense anymore, what you can effectively/efficiently cache changes, and it may not make sense to hook that cache in at such a low level anymore -- it starts making more sense to talk about caching request=>response pairs (with pagination and field lists baked into them) instead of caching individual DocLists and DocSets ... at that level hooking into memcached might make sense, but it's probably easier and just as effective to use something like squid as a proxy cache in front of SOlr instead. (that's what i do) -Hoss
