[jira] Issue Comment Edited: (SOLR-139) Support updateable/modifiable documents
[
https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522310
]
ehatcher edited comment on SOLR-139 at 8/23/07 4:59 PM:
There is a bug in the last patch that allows an update to a non-existent
document to create a new document.
I've corrected this by adding this else clause in
ModifyExistingDocumentProcessor:
if( existing != null ) {
cmd.solrDoc = ModifyDocumentUtils.modifyDocument(existing, cmd.solrDoc,
modes, schema );
} else {
throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
Cannot update non-existent document: + id);
}
I can't generate a patch, yet, that is clean addition of just that bit of code
along with the other changes.
was (Author: ehatcher):
FYI - I'm looking into tracking it down, but there is a bug in the latest
patch that allows an update to a non-existent document to create a new
document. More when I figure out the cause.
Support updateable/modifiable documents
---
Key: SOLR-139
URL: https://issues.apache.org/jira/browse/SOLR-139
Project: Solr
Issue Type: Improvement
Components: update
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: getStoredFields.patch, getStoredFields.patch,
getStoredFields.patch, getStoredFields.patch, getStoredFields.patch,
SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch,
SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch,
SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch,
SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch,
SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch,
SOLR-139-IndexDocumentCommand.patch, SOLR-139-ModifyInputDocuments.patch,
SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch,
SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch,
SOLR-269+139-ModifiableDocumentUpdateProcessor.patch
It would be nice to be able to update some fields on a document without
having to insert the entire document.
Given the way lucene is structured, (for now) one can only modify stored
fields.
While we are at it, we can support incrementing an existing value - I think
this only makes sense for numbers.
for background, see:
http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522333 ] Yonik Seeley commented on SOLR-139: --- how about using update instead of add We had previously talked about making this distinction (and configuration for each field) in the URL: http://localhost:8983/solr/update?mode=title:overwrite,cat:distinct This makes it usable and consistent for different update handlers and formats (CSV, future SQL, future JSON, etc) but perhaps if we allowed the add tag to optionally be called something more neutral like docs? wrt patches, I think the functionality needs refactoring so that modify document logic is in the update handler. It seems like it's the only clean way from a locking perspective, and it also leaves open future optimizations (like using different indices depending on the fieldname and using a parallel reader across them). Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: Improvement Components: update Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch, SOLR-269+139-ModifiableDocumentUpdateProcessor.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-247) Allow facet.field=* to facet on all fields (without knowing what they are)
[ https://issues.apache.org/jira/browse/SOLR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522345 ] Pieter Berkel commented on SOLR-247: Some recent discussion on this topic: http://www.nabble.com/Structured-Lucene-documents-tf4234661.html I get the impression that general wildcard syntax support for field listing parameters (i.e. the reverse of dynamic fields) as described in the above thread would be far more useful than a simple '*' match-anything syntax (not only in faceting but other cases like hl.fl and perhaps even mlt.fl). I haven't really considered the performance issues of this approach however, as it would involve checking each field supplied in the parameter for '*' before expanding it into full field names for every query. Given the above, the fact that it could be used across multiple response handlers and subhandlers like SimpleFacets Highlighting, and that it would require access to IndexReader to getFieldNames(), where might be the most sensible place to put this code? Allow facet.field=* to facet on all fields (without knowing what they are) -- Key: SOLR-247 URL: https://issues.apache.org/jira/browse/SOLR-247 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Priority: Minor Attachments: SOLR-247-FacetAllFields.patch I don't know if this is a good idea to include -- it is potentially a bad idea to use it, but that can be ok. This came out of trying to use faceting for the LukeRequestHandler top term collecting. http://www.nabble.com/Luke-request-handler-issue-tf3762155.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
