|
Hi,
thanks for answer. The whole search facility and the limitations to it are really a show stopper! I can't believe that the folks at atlassian did not take the limitation with asterisks at the beginning of a search term into consideration before switching to lucene. It renders the search almost useless and this is the only point that lets the great product look a bit "clumsy".
Is there any workaround like another SearchProvider (based on MySQL-Indexing or plain SQL)? Steve,
In your case, is there a way of knowing how to split the words? For example, if you know that you are using CamelCase, then we can index both Camel and Case. Peter - can you give some examples of the searches that you are looking to perform? hi,
when we search in java source code, many class names are CamelCase words. Some practical grep funcionality will really us help to find a wiki document. Sometime we have many mispelled words when typing too fast with keyboard. E.g. "there is aduck". In this case just a simple space character is missing. So we will never find that duck. As mentioned above just a simple search like java.lanf.String#indexOf is Unable to render embedded object: File (really) not found. sufficient for us and performance won't be that a big issue us. Currently we use PowerGrep (http://www.powergrep.com/  ) mostly for performing that same searching on text/binary files which are located in the confluence attachment directory.steve Exactly the same as shown in the description.
"CamelHump awareness" would help a bit. My point is that people are used to "sub word matching" search engines. Clarifying the summary.
(I agree, not being able to do substring searches is often annoying. It is useful to keep an archive of email notifications for this sort of searching.) I agree this is something that should be high priority for Atlassian to fix.
If I have a hostname of www1la I can't search for www to find all tickets with that machine in the subject. Sean,
Thanks for your input. While this issue is indeed important (as Jeff will attest to) we do have a development process that is based on popularity of issues. You can see at http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements Cheers Mark C Mark,
thanks for making clear how decisions are made. But still I can't understand why issues that most people consider a show stopper are not on the development roadmap for really a long period of time. This BUG (this isn't a "New Feature") renders the search quite useless IMHO. If I were given 5 cents per request like "I did search for issue xyz but I did not find it so I created a new one" from our test team... Same with another annoying issue: Buld Workflow Transition ( Don't get me wrong - I like JIRA a lot, but still I miss some things... Peter,
We definitely hear your frustrations! As you do point out though, there are still plenty of outstanding issues features that many people want Thanks for you patience & understanding on this! Cheers, Mark C I have linked some similar issues. Please look out for such similar issues. Thanks
Steve Bugzilla http://bugzilla.org
has had this for quite some time. It's really useful to be able to search for parts of Java stack traces that are entered into comments or issue descriptions.
You all should pay special attention to this issue regardless of the few votes. You have to realize that some bugs won't get votes because people don't know that there is something wrong... Most people just won't find what they want when searching and won't know why and they'll think badly of JIRA. Just wanted to add that the lack of being able to search for XYZ and have JIRA return each and every entry containing XYZ is very important for us, too. In fact, this is a close to a show-stopper ("can't buy jira because full-text search doesn't work as expected") for us.
Hello, As of Lucecen 2.1 prefix search is possible!!
Read this: http://wiki.apache.org/lucene-java/LuceneFAQ#head-4d62118417eaef0dcb87f4370583f809848ea695 "Leading wildcards (e.g. *ook) are not supported by the QueryParser by default. As of Lucene 2.1, they can be enabled by calling QueryParser.setAllowLeadingWildcard( true ). Note that this can be an expensive operation: it requires scanning the list of tokens in the index in its entirety to look for those that match the pattern. " So how can I apply easily a "setAllowLeadingWildcard(true)-Fix in Jira and Confluence ? Hi Steve,
We recently upgrade Lucene in JIRA to 2.2.0, which makes this feature fairly easy to implement. We simply need to allocate some time + resources and schedule it. However if one was going to implement this, you'd basically have to make sure that all the QueryParsers that get created in JIRA have the setAllowLeadingWildcard flag set to true. Preferably this could be done via a new ApplicationProperty, that can be set via the 'General Configuration' in the admin section. The places that need to be changed on a quick glance are:
We should probably add a 'getQueryParser' method to the IndexManager, and change the 3 places above to use that method to retrieve the QueryParser. The IndexManager would then be responsible for setting the allowLeadingWildcard flag depending on an applicationProperty. Cheers, Re " We recently upgrade Lucene in JIRA to 2.2.0, which makes this feature fairly easy to implement. We simply need to allocate some time + resources and schedule it."
Please schedule it. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Critical
Allow searching for part of a word (prefix / substring searches)
Seriously, you just don't find issues unless you use some filter and scan a LOT of messages by hand.
We are working on a solution as it would be great to get this done. However, we do not have any concrete time lines in place at the moment for this feature.
I believe there are 'hacks' floating around the Lucene mailing list that enable lucene to do substring matches. However you will still need to patch JIRA as there are checks in place to ensure that the search term does not start with "*".
Another way to do this would be to write a listener that would index issues in its own index and then extend JIRA's issue navigator to search that index as well. More information on listeners can be found here:
http://www.atlassian.com/software/jira/docs/latest/listeners.html