Lucene search backend #8963
Closed
Lucene search backend #8963
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A user might have deleted a link to a fulltext-file in the source tex file and we need to reflect that change in the index as well.
btut
commented
Jul 12, 2022
Comment on lines
92
to
97
| HashMap<String, Float> boosts = new HashMap<String, Float>(); | ||
| SearchFieldConstants.searchableBibFields.stream().forEach(field -> boosts.put(field, Float.valueOf(4))); | ||
|
|
||
| if (query.getSearchFlags().contains(SearchRules.SearchFlags.FULLTEXT)) { | ||
| Arrays.stream(SearchFieldConstants.PDF_FIELDS).forEach(field -> boosts.put(field, Float.valueOf(1))); | ||
| } |
There was a problem hiding this comment.
Easy, but ugly. Maybe define a boost property for the standard Fields and get that by Field-name?
|
Very nice to see this implemented! A few comments from my side:
|
Would definitely reduce coding effort and migration code.
Thought about that too, maybe with the option for power-users to show floats instead. I am very bad at UI design though, did not get good feedback whenever I implemented something, so would need some help with that.
Thats true, but filtering kind of defeats the purpose of a fulltext/fuzzy search IMO. Where do you draw the line for the filtering predicate? Score==0? In large libraries that will result in a table with lots of "bad" search results with scores slightly above 0 and people could need to scroll to find much better matches.
In any case, we would need to have a very nice way to display the score if we do not sort on it, so users can still tell better fits apart. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
gradlew clean? |
|
Gradlew clean fixed the compilation, but now I get the following errors whenever I try to open a library: and |
|
hm, interesting, can reproduce the bug on my windows machine, but not on my arch linux laptop |
# Conflicts: # CHANGELOG.md # src/main/java/org/jabref/model/search/rules/ContainsBasedSearchRule.java # src/main/java/org/jabref/model/search/rules/GrammarBasedSearchRule.java # src/main/java/org/jabref/model/search/rules/RegexBasedSearchRule.java
# Conflicts: # CHANGELOG.md # src/main/java/org/jabref/model/search/rules/ContainsBasedSearchRule.java # src/main/java/org/jabref/model/search/rules/GrammarBasedSearchRule.java # src/main/java/org/jabref/model/search/rules/RegexBasedSearchRule.java
|
The build of this PR is available at https://builds.jabref.org/pull/8963/merge. |
This was referenced Oct 13, 2023
|
|
I will just mention this my old comment here as well, so that it is not forgotten: #4237 (comment) I have noted that for the Lucene search approach (#8963 (comment)), the following solution has been suggested to the 'floating mode' problem: I am not familiar with the technicalities of Lucene, but I reckon a score of 0 represents an item, that does not match the search criteria at all. That is not (!) the same as what the old floating mode in JabRef 3.8.2 offered - the items in gray did match the search criteria to a certain degree. The only difference between the items with white background and those with gray background was, that the white ones belonged to the group, that the user had selected at the moment. The gray ones did not (!) belong to the selected group. Hopefully, this old behaviour of JabRef can be restored with the new Lucene search. |
|
Some notes on the search syntax. Users might find it confusing if partial-word-search is not the default search. See laurent22/joplin#6349 and laurent22/joplin#6455 for discussions in a related project. Full search documentation of Joplin: https://joplinapp.org/help/apps/search |
LoayGhreeb
added a commit
to LoayGhreeb/jabref
that referenced
this pull request
Jul 1, 2024
6 tasks
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jul 24, 2024
* Fix selecting group triggers in all open libraries * Change color of the search modifier buttons for dark theme #8963 (comment) * Add shortcut to open global search window "Ctrl+shift+F" * fix keep on top subscription * Fix context menu of the search bar * Store preview divider position in global search window Remove constructor * prevent NPE * Fix update search query triggers in all open libraries * Adapt GUI test * Clear search highlight in SourceTab after resetting search query * Revert "Fix update search query triggers in all open libraries" This reverts commit d6d455c. * Revert "Fix selecting group triggers in all open libraries" This reverts commit b0017fb. * Remove regexValidator * listen for changes for search flags --------- Co-authored-by: Siedlerchr <siedlerkiller@gmail.com>
|
Follow-up PR: #11542 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First draft of the switch to the Lucene Search Backend
Whats working
Todo
Follow-ups
Problems:
Fixes #8857
CHANGELOG.mddescribed in a way that is understandable for the average user (if applicable)