Re: [Exist-open] [ exist-Bugs-3182464 ] util:expand() throws offset out of bounds on ft:query() hits

[Casey J. <cas...@jo...>]

Has there been any progress on this bug? I am testing the latest 1.4.1 and
this seems to be the only thing that is preventing me from testing 1.4.1 in
a production environment.

Thanks,

Casey

On Tue, Feb 15, 2011 at 11:35 AM, SourceForge.net
<no...@so...>wrote:

> Bugs item #3182464, was opened at 2011-02-15 16:35
> Message generated for change (Tracker Item Submitted) made by
> You can respond by visiting:
>
> https://sourceforge.net/tracker/?func=detail&atid=117691&aid=3182464&group_id=17691
>
> Please note that this message will contain a full copy of the comment
> thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: rvdb ()
> Assigned to: Nobody/Anonymous (nobody)
> Summary: util:expand() throws offset out of bounds on ft:query() hits
>
> Initial Comment:
> Both eXist-trunk (rev. 13778) and eXist-1.4.x (rev. 13754) in some cases
> generate incorrect start offsets for match highlighting of hits found with
> the ft:query() search function.
>
> Attached is a XQuery Unit test file illustrating the problem
> (startOffsetTest.xml). The problem appears to be related to the complexity
> of elements that happen to precede a ft:query() hit. I only see problems
> when a hit is preceded by a complex element containing another element
> (either empty or with text content). Both clearly produce mismatched start
> offsets (see failing tests #7-#10). When the query matches the first string
> after such a complex node, an exception is thrown (failing tests #7, #9);
> when the second word is matched, the offset appears to be one position early
> (failing tests #8, #10). Note that the exception differs when match is
> immediately preceded by a complex element with text content (failing test
> #7: "start offset out of bounds"), or by a complex element with an empty
> element (failing test #9: just "Compilation error: -1").
>
> OTOH, there are no problems:
>   -when the matching node does not contain any elements preceding the match
> (succeeding tests #1-#2)
>   -when the elements immediately preceding a match do not contain nesting
> elements, be they empty or having just text content (succeeding tests #3-#6)
>
> The errors seem to have been introduced after rev. 13592 (trunk) and rev.
> 13705 (1.4.x). I suspect it might have something to do with commits
> affecting symbols.dbx or the lucene index.
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
>
> https://sourceforge.net/tracker/?func=detail&atid=117691&aid=3182464&group_id=17691
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Exist-open mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-open
>



-- 
--
Casey Jordan
easyDITA a product of Jorsek LLC
"CaseyDJordan" on LinkedIn, Twitter & Facebook
Cell (585) 348 7399
Office (585) 239 6060
easydita.com


This message is intended only for the use of the Addressee(s) and may
contain information that is privileged, confidential, and/or exempt from
disclosure under applicable law.  If you are not the intended recipient,
please be advised that any disclosure  copying, distribution, or use of
the information contained herein is prohibited.  If you have received
this communication in error, please destroy all copies of the message,
whether in electronic or hard copy format, as well as attachments, and
immediately contact the sender by replying to this e-mail or by phone.
Thank you.