[
https://issues.apache.org/jira/browse/SOLR-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756469#action_12756469
]
Fergus McMenemie edited comment on SOLR-1437 at 9/17/09 3:53 AM:
-----------------------------------------------------------------
Good points.
I am still make sure I understand the existing code completely. Adding lots of
comments.
I was not going to allow wild-cards in the forEach parameter. Can you think of
a use case?
Your second point is covered. At this point my plan is to scrap skipTag,
replacing it with equivalent inline code. Then after I have found some way of
recording //tagnames within the node tree (I am considering the fact that
currently it is invalid for the rootNode to have attributes; and I was thinking
of abusing the rootNode attributes field and using it to store //tagname Node
trees). Then where skipTag would currently be called, I would instead compare
the parsed localname against the "attributes" of the rootTag.
Potential issues I intend to ignored are. If we have:
{noformat}
column="e" xpath="//e/f...@qualifier='fullTitle']"
column="d" xpath="/a/b/c/d" flatten="true"
{noformat}
and the XML stream contains
{noformat}
/a/b/c/d/e...
{noformat}
Then I will not populate column 'e'. Also the expression for column 'd' which
is an absolute Xpath takes precedence over that for column 'e'.
Thoughts?
was (Author: fergus):
Good points.
I am still make sure I understand the existing code completely. Adding lots of
comments.
I was not going to allow wild-cards in the forEach parameter. Can you think of
a use case?
Your second point is covered. At this point my plan is to scrap skipTag,
replacing it with equivalent inline code. Then after I have found some way of
recording //tagnames within the node tree (I am considering the fact that
currently it is invalid for the rootNode to have attributes; and I was thinking
of abusing the rootNode attributes field and using it to store //tagname Node
trees). Then where skipTag would currently be called, I would instead compare
the parsed localname against the "attributes" of the rootTag.
Potential issues I intend to ignored are. If we have:
{{
column="e" xpath="//e/f...@qualifier='fullTitle']"
column="d" xpath="/a/b/c/d" flatten="true"
}}
and the XML stream contains
{{
/a/b/c/d/e...
}}
Then I will not populate column 'e'. Also the expression for column 'd' which
is an absolute Xpath takes precedence over that for column 'e'.
Thoughts?
> DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
> ----------------------------------------------------------------------------
>
> Key: SOLR-1437
> URL: https://issues.apache.org/jira/browse/SOLR-1437
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
> Affects Versions: 1.4
> Reporter: Fergus McMenemie
> Assignee: Noble Paul
> Priority: Minor
> Fix For: 1.5
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> As per
> http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html
> it would be nice to be able to use expressions such as //tagname when
> parsing XML documents.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
