> >> >> Our index could be much smaller if we could store some of fields not in >> index directly but in some kind of external storage. >> All I've found until now is ExternalFileField class which shows that it's >> possible to implement such a storage, but I'm quite sure that the >> requirement is common and there should be some existing implementations. >> Also it would be good to be able to search using these fields, to include >> them in the search result sets and to update them with standard Solr >> update >> handlers. >> >> >> > Thats a tall order. It almost sounds as if you want to be able to not use > the index to store fields, but have them still fully functional as if > indexed. That would be quite the magic trick.
Well there's a number of posts in different mail lists which talk about the same requirements so I wonder is lucene/solr/smth else doesn't implement something like this. For example, see this post: http://markmail.org/message/t4lv2hqtret4p62g?q=lucene+storing+fields+in+external+storage&page=1&refer=bmode2h2dwjpymba#query:lucene%20storing%20fields%20in%20external%20storage+page:1+mid:t4lv2hqtret4p62g+state:results > You might check out http://skwish.sourceforge.net/. Its a cool little > library that lets you store arbitrary data keyed by an auto generated id. We already have the storage (Coherence), we just want to make it accessible through standard Solr API and not to create an additional logic above Solr. I mean the logic which processes result sets and add additional fields to it by taking values from the external storage. And in the case of that custom post-search logic we also will have to implement some additional filtering/ordering/etc of result sets based on values of that "external" fields. So the question is is it possible to use Solr/Lucene features to use external field storage for some of fields. -- Andrew Klochkov
