MaxCutoffLimit when using wildcard search RRS feed

  • Question

  • Hi everybody,


    We are having some difficulties implementing a search based solution which uses the FAST Search for SharePoint over its QueryManager API. 

    The client would like to have a full wildcard search on more than one managed property available. For our project, we added a few (around 15) managed properties to the FAST Index, containing the information we need. In the front end of the solution, we would like to be able to enter a search term for some of these properties, and then perform a full wildcard search with the term.

    So: input field which corresponds to managed property "prop1" gets "test" as an input. We would then like to take the input string, add a "*" as a prefix and a suffix, and query using the api with the searchstring 'prop1:"*test*"'. Now we found out that this would trigger the MaxCutoffLimit of the FAST Engine, since actually we are searching for "*" in the field "prop1" (which has over 30k unique entries) as the search string starts with that. So we've decided to take off the "*" at the beginning of the string, and just work with 'prop1:"test*"': This however, means that we are not really meeting the requirement by our client, since we would only find string like "test123", and not "123test123".

    Does anyone have a better idea to solve this issue? FAST should support full wildcard search, but it seems to be really restricted in use because of this maxhardcutofflimit.

    A second requirement we have, is a functionality that I can describe as the classic database "contains" operator. we would like to provide a full wildcard textsearch on the entire group of managed properties I described above. First we tried by just adding the search string (with "*" at the beginning and the end) without a field to the query. This however seemed to immediately trigger the cutoff limit. So then we decided to use fieldsearch to achieve this functionality, by adding all of the managed properties and the search string to a big OR-clause, like so:

    OR(prop1:"*test*",prop2:"*test*",prop3:"*test*", ... ). 

    This seemed to work for smaller data collections, but in the productive environment, we reached the cutoff limit again. 

    For this scenario we now want to try the same solution as for the first point, being, deleting the "*" at the beginning of the input string, so it would become:

    OR(prop1:"test*",prop2:"test*",prop3:"test*", ... ). 

    In FAST ESP we could define composite fields to solve issues like this. Is it possible to do the same in the FAST Search for SharePoint environment?

    And can anybody help with the wildcard support in FAST Search for SharePoint, since we would really like to implement the full wildcard search instead of just the suffix wildcard...!

    Thanks in advance!



    Monday, January 30, 2012 11:09 AM

All replies

  • Can you shed some light on the MaxCutOffLimit documentation for FAST? I cannot seem to find anything on this. Are you using FQL or just keyword syntax?
    Blog | SharePoint Field Notes Dev Tool | ClassMaster
    Monday, January 30, 2012 5:09 PM
  • Hi Steve,


    I can't seem to find anything useful as well, but I read the topic where Thomas Svensen and Knut Brandrud discussed this problem: http://social.technet.microsoft.com/Forums/en-US/fastsharepoint/thread/944e4272-f4ec-4448-b791-71e103dbfbe0/. It seems that is is possible to increase the MaxCutoffLimit (a parameter in fsearch.addon) but I am not sure if this is the way to go. The error that is appearing in the query logs ends with: 

    MANAGED(0, 0) STATS(0.0000, 0.0000, 0) ERROR(1013))]

    The error the querymanager is returning (well not really an error, but it has a property called "exception") is: "The creator of this error did not specify a reason" or something along those lines. This is absolutely not helping anyone, since the returned result is a "null".


    Tuesday, January 31, 2012 8:50 AM