[bt-devel] [ bibletime-Bugs-1466309 ] Unordered search results

[SourceForge.net]

Bugs item #1466309, was opened at 2006-04-07 13:03
Message generated for change (Settings changed) made by jim-campbell
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100954&aid=1466309&group_id=954

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: Frontend / Search dialog
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Wolfgang Stradner (ewst)
Assigned to: Jim Campbell (jim-campbell)
Summary: Unordered search results

Initial Comment:
The results of searches (not of the find tool) are
unordered, I cannot find a system of any order used.
This makes it difficult to find the next search result
(hit) following in the text.

-> Put them in the order of biblical books, (and if
this does not work in an alphabetic order of biblical
books)

----------------------------------------------------------------------

Comment By: Jim Campbell (jim-campbell)
Date: 2006-04-09 03:49

Message:
Logged In: YES 
user_id=689979

Committed to cvs 2006-04-08.

----------------------------------------------------------------------

Comment By: Jim Campbell (jim-campbell)
Date: 2006-04-08 21:19

Message:
Logged In: YES 
user_id=689979

Thanks, I completly overlooked that one.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-04-08 18:26

Message:
Logged In: NO 

The method Testament() of  Versekey is your friend for 2) 

:)

----------------------------------------------------------------------

Comment By: Jim Campbell (jim-campbell)
Date: 2006-04-08 18:10

Message:
Logged In: YES 
user_id=689979

This is turning out to be more difficult than first
anticipated.  
1) There is no way to insert results into the searchResult.
      sword::ListKey m_searchResult;
   Therefore, the order must be determined before adding
them to the searchResult.  This not necessarly a problem,
but it does consume a fair ammount of processor time.  I can
make this faster by using a temporary list that does support
insert.  But I need to solve problem 2 first.

2) The "Index()" is only valid for each Testament.  For
example the Index() of Genesis is 1-??? and the Index() of
Matthew is 1-???.  Therefore, Index() is not relilable
unless there is a way to determine the Testament of the key
as well.

Any thought or hints would be appriciated.

----------------------------------------------------------------------

Comment By: Jim Campbell (jim-campbell)
Date: 2006-04-07 16:24

Message:
Logged In: YES 
user_id=689979

As long as the index is relevent to the Biblical order of
the key, I see no problem with ordering the search results
(keys) according to the index.

I am not exactly sure on your alternate option.  I am not
familiar with the sword internals and indexing.  But
wouldn't the results still have to be sorted either way?

I will do the sorting according Joachim's suggestion because
I feel more comfortable with that solution.

----------------------------------------------------------------------

Comment By: Martin Gruner (mgruner)
Date: 2006-04-07 15:58

Message:
Logged In: YES 
user_id=169722

This is something we need to work on. Jim, I am assigning
this to you as well -- as usual, you can always reassign it
to "nobody" if you don't want to handle this or have no time.

We cannot rely on clucene 0.9.11 -- this might take longer
than BT 1.6. Therefore we have to find a workaround for this
problem until 0.9.11 is released.

Joachim said that there is a place where the results of a
clucene search are fed into the parser of sword to return
VerseKeys. Could we use this loop to also order the keys
according to their Index() (i believe it is called in
sword)? This should be simple to do, and is only needed
until clucene 0.9.11, so we can mark it as temporary code.

Another option: we could store the index in the document, in
a field like sword_index: for fast lookup. But since we have
to parse the keys anyway, we might not win speed with this
solution, and the index would get bigger. What do you think?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100954&aid=1466309&group_id=954