+1 to letting consciously-coded indexing handlers actually get what they ask for. I think way too extreme a swing got made from the "index anything JavaScript decides to send and assume it will all work for the best" world of the Sling+Jackrabbit combo to the "install a half-dozen roadblocks to discourage any progress" approach.
The evidence shows that we need more coherent attention paid to what actually goes _into_ those indexing handlers and the queries they support. But it's easier to give coherent attention to one code location than to multiple Java, XML, and JSON locations scattered around three repositories. Best, Ray On 5/10/12 11:00 PM, Carl Hall wrote: > This was something Ian implemented when he introduced Solr. The only > explanation I've heard is what I put in the code doc in the source. I > think that the check overlooks the _source field is a bug and is the > easiest fix. Whether or not we should be checking for fields beyond > system props seems unnecessary to me since the indexing handler thought > the data was important enough to introduce the document. > > Are there any arguments against removing this check and letting whatever > docs that are introduced by the indexing handlers be sent to Solr? > > > On Thu, May 10, 2012 at 4:56 PM, Duffy Gillman <[email protected] > <mailto:[email protected]>> wrote: > > I've found a bit of a paradox in SparseIndexingServiceImpl. It > appears there is a bit of code designed to omit useless indexing > data (SolrInputDocuments consisting only of system properties), but > elsewhere in the code IndexingHandlers are held to a contract that > prevents them from creating indexing data with only the system > properties that are being checked. This means either the check is > superfluous or needs to be modified. > > Anyone have an informed opinion on this? > > More info: https://jira.sakaiproject.org/browse/SOLR-72 > > Thanks, > Duffy > > ------------------------------ > Duffy Gillman > Sr. Software Engineer > The rSmart Group, Inc. > > _______________________________________________ > oae-dev mailing list > [email protected] <mailto:[email protected]> > http://collab.sakaiproject.org/mailman/listinfo/oae-dev > > > > > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
