The implementation assumed that most of the users have xml with a
fixed schema. . In that case giving absolute path is not hard. This
helps us deal with a large subset of usecases rather easily.
We have not added all the features which are possible with a
streaming parser. It is wiser to piggyback
>: > The solr data field is populated properly. So I guess that bit works.
>: > I really wish I could use xpath="//para"
>
>: The limitation comes from streaming the XML instead of creating a DOM.
>: XPathRecordReader is a custom streaming XPath parser implementation and
>: streaming is easy only b
There are two xml library projects that do streaming xpath reads with full
expression evaluation: Nux and dom4j. Nux is from LBL and is an "kinda like
BSD" license and dom4j is BSD license.
http://dom4j.org/dom4j-1.6.1/project-info.html
http://acs.lbl.gov/nux/
The licensing probably kills these,
On Wed, Feb 4, 2009 at 6:13 AM, Chris Hostetter
wrote:
>
> : > The solr data field is populated properly. So I guess that bit works.
> : > I really wish I could use xpath="//para"
>
> : The limitation comes from streaming the XML instead of creating a DOM.
> : XPathRecordReader is a custom streami
: > The solr data field is populated properly. So I guess that bit works.
: > I really wish I could use xpath="//para"
: The limitation comes from streaming the XML instead of creating a DOM.
: XPathRecordReader is a custom streaming XPath parser implementation and
: streaming is easy only becaus
On Tue, Feb 3, 2009 at 11:59 AM, Fergus McMenemie wrote:
> The solr data field is populated properly. So I guess that bit works.
> I really wish I could use xpath="//para"
>
>
The limitation comes from streaming the XML instead of creating a DOM.
XPathRecordReader is a custom streaming XPath pars
The solr data field is populated properly. So I guess that bit works.
I really wish I could use xpath="//para"
>A separate problem: when I used the DIH in December, the xpath
>implementation had few features. '[...@qualifier='Date']' may not be
>supported.
>
> dateTimeFormat="MMdd" />
>
>
this syntax is supported /record/metadata/da...@qualifier='Date']. if
I am not wrong and there is a testcase also for that
On Tue, Feb 3, 2009 at 7:20 AM, Lance Norskog wrote:
> A separate problem: when I used the DIH in December, the xpath
> implementation had few features. '[...@qualifier='Dat
A separate problem: when I used the DIH in December, the xpath
implementation had few features. '[...@qualifier='Date']' may not be
supported.
On Mon, Feb 2, 2009 at 9:24 AM, Noble Paul നോബിള് नोब्ळ् <
noble.p...@gmail.com> wrote:
> this patch must help
>
> On Mon, Feb 2, 2009 at 10:49 PM,
this patch must help
On Mon, Feb 2, 2009 at 10:49 PM, Shalin Shekhar Mangar
wrote:
> On Mon, Feb 2, 2009 at 10:34 PM, Fergus McMenemie wrote:
>
>>
>> Is there some simple escape or other syntax to be used or is
>> this an enhancement?
>>
>
> I guess the problem is that we are creating the regex
On Mon, Feb 2, 2009 at 10:34 PM, Fergus McMenemie wrote:
>
> Is there some simple escape or other syntax to be used or is
> this an enhancement?
>
I guess the problem is that we are creating the regex Pattern without first
resolving the variable. So we need to call VariableResolver.resolve on th
RegexTransformer does not replace the placeholders before processing the regex.
it has to be enhanced
On Mon, Feb 2, 2009 at 10:34 PM, Fergus McMenemie wrote:
> Hello
>
> As per several postings I noted that I can define variables
> inside an invariants list section of the DIH handler of
> solr
Hello
As per several postings I noted that I can define variables
inside an invariants list section of the DIH handler of
solrconfig.xml:-
data-config.xml
/Volumes/spare/ts
I can also reference these variables within data-config.xml. This
works,
13 matches
Mail list logo
