December 2010 - Posts
SharePoint 2010 has three syntaxes that you can use to execute search queries, Keyword, SQL, and FAST Query Language (FQL). In SharePoint 2007, we only had the first two of course. You may not know it, but you probably use Keyword Query Syntax every day when you visit your search center. This is your basic keyword search, but in reality it has become extremely powerful now in SharePoint 2010. This wasn’t the case with SharePoint 2007. Keyword Syntax did not support wildcard search, comparison operators, or Boolean operators. This often led people to develop custom code solutions using the FullTextSqlQuery class (or the web service) to use the SQL Syntax which supported these advanced query scenarios.
SharePoint 2010 changed everything though. They added wildcard search, comparison operators, Boolean operators, proximity operators, and synonym operators to the Keyword syntax. All of these things were previously available using SQL Syntax, but now you can do them using Keyword Syntax in SharePoint 2010. Since all of these new features have been added, in my eyes, this effectively (but not officially) makes the SQL Syntax deprecated. I’ve never been a big fan of the SQL Syntax but there were times in 2007 that it was a necessary evil. Unfortunately, when you used it in the CoreResultsWebPart, it prevented you from using a bunch of other features such as best bets, keyword highlighting, RSS, federated search and more. Since the Keyword Syntax supports all of these new operators now, you can get that functionality and not worry about having to lose other desired functionality that you did with Full Text SQL Queries.
You can write really advanced queries with Keyword Syntax. For example:
shirt Color:Red AverageRating >= 4 NOT Department:”Sales”
This would return anything with the word Shirt in it with a color property value of red, rated at least 4 stars and it can’t be from the sales department. As another example:
budget Scope:”Local SharePoint Sites” Scope:”Corporate Web Site” NOT Scope:”File Share”
This would return results matching the word budget from the scopes pointing to the SharePoint site itself as well as the corporate web site, but it would exclude results from the file share. The Keyword syntax has a lot of power now and I think you will be hard pressed to find a query it can’t do.
Another reason to use the Keyword syntax is that both SharePoint Search and FAST Search support it. If you wrote a custom application using SharePoint Search and Keyword queries and later decided to implement FAST, your queries would still work (assuming you indexed the same content). That gives you a ton of code portability.
Of course, if you don’t believe me, take a look at the SDK where they list the following tip.
“The Keyword syntax enhancements in SharePoint Server search provide support for functionality that was previously available only by using SQL syntax, such as comparison, logical, and wildcard operators. If the Keyword syntax meets the requirements for the queries you need to construct for your custom search application, we recommend that you use it instead of the SQL syntax. You should also use the Keyword syntax if you are creating an application that is intended for use with both FAST Search Server 2010 for SharePoint and SharePoint Server search.”
What about FAST? FQL is extremely powerful and you should take advantage of it in your advanced search scenarios. The cool thing about FQL is that it also uses the KeywordQuery class by setting the EnableFQL property to true. This in a lot of ways makes it an extension to the Keyword Query syntax. You can use FQL or Keyword Syntax to execute search queries in FAST. I recommend using Keyword Syntax for most queries but when you need more control of how the query or results are presented, you should switch to FQL.
All of this is just my opinion of course. If you have some overwhelming reason that you need to use SQL Syntax, then by all means continue. However, I recommend to anyone starting out writing search code to try the Keyword Syntax first.
There is a setting that you can find in SharePoint Enterprise Search to automatically generate a new managed property for each crawled property discovered in a particular category. You find this setting in your Search Service Application under Metadata Properties –> Categories. The category we deal with the most is SharePoint since site columns from SharePoint end up here. Click on the arrow next to SharePoint and choose Edit Category.
On this screen, you will see the option in question under Automatically discover new properties when a crawl takes place. It is labeled as Automatically generate a new managed property for each crawled property discovered in this category.
I hesitated a bit before I tried this property because I was afraid that my managed properties would get filled with a bunch of junk. I proceeded anyway to see what would happen though. After, I set it I did an incremental crawl. I went back to my SharePoint crawled properties category page when it finished and I was surprised to not find that anything changed. I still had many unmapped crawled properties. I then decide to try a full crawl and again I didn’t see any changes. I decide this is a good thing though. I would really only prefer that it map my own custom crawled properties as opposed to the heap of ones that are already there.
At this point, it was clear to me that this setting only affected new crawled properties. I quickly created a new Site Column in a list called TestColumn. I performed yet another incremental crawl and sure enough I had a new managed property created as well. Take a look.
It created the new managed property for us named owsTestColumn. As you may know all SharePoint site columns get prefixed with ows_ as crawled properties. It kept the ows prefix when it created the managed property. At this point, I have a fully usable managed property that I did not have to create manually.
So do I recommend you use this setting? Well if you happened to read my SharePoint Naming Conventions Guide on NothingButSharePoint.com, you would know that the answer is no. I don’t like the ows prefix. The point of managed properties is to create an abstraction layer so that you can get some consistency in the names you work with in search. The other reason I recommend against it is in case you have site columns named different things (for example ProductId and ProdId). So in theory, it sounds like a good idea, but it really isn’t worth using in the end. That’s just my opinion though. If you think it will work for you then I encourage you to try it out. Also remember if you need to test a lot of managed properties consider using PowerShell. This is a great way to create managed properties in new environments.
I had the pleasure of returning to Kansas City this weekend for my third SharePoint Saturday up there. I got to see some old friends and make some new ones. Thanks to everyone that helped make it possible. I presented two talks this time Beginning SharePoint Development for ASP.NET Developers and How the SharePoint BCS can change your life. Both talks had a pretty good turnout and I hope everyone learned a lot. I’ve posted my slide decks up on SlideShare. Thanks for coming and feel free to let me know if you have any questions.
Beginning SharePoint Development for ASP.NET Developers
How the SharePoint BCS can change your life
I’ve never been a fan of the way contextual search is handled in SharePoint out-of-the-box. By default, SharePoint has contextual searches go to OSSSearchResults.aspx. If you aren’t familiar with the term contextual search, you might be familiar with the This Site or the This List search scope options that you see in the search drop down list.
The reason I don’t like OSSSearchResults.aspx (besides all of the S in the page name) is that it is an application page and is generally considered not customizable. This means if you want to configure how results are displayed or the refinement panel, you really can’t directly (without leaving yourself in an unsupported state). You can make a copy of it and then make customizations, but that is a lot of effort for something so simple.
I understand why SharePoint uses this page by default though. The first reason is that SharePoint Foundation does not have a Search Center site template and it needs some place to render search results. Secondly, even if you have SharePoint Server, you may not have created a search center. Therefore, it uses this page by default so that search will work without any major configuration.
We want to customize what is on the contextual search page though. What you can do is reconfigure the Site Collection Search Results Page URL to point to your search center. We can find this setting in the Search Settings page of your site collection settings. I talked about these settings in the past. When you go to this page, you will see that the URL configured is /_layouts/OSSSearchResults.aspx.
We simply change this to the URL of the results.aspx page in your Search Center. Now, typically I install my search center on a URL such as /Search or /SearchCenter. Determine what your URL is or go create a search center using the New Site menu. In my example, we'll use /search. You will find the results.aspx page in the Pages library, so the full URL we want is /Search/Pages/Results.aspx. You can also determine this URL by going to your search center and performing a search. When you enter the URL, leave out the server name.
Once you have finished, we can test our contextual search from any site or document library.
As you can see, our search results are now in the Search Center and we have things like people search showing up. However, the results only contain the contextual information from the subsite. Now, I can customize this page as needed. The CoreResultsWebPart actually uses two extra query string parameters to make this happen. The cs parameter has the contextual scope name, This Site. The u parameter specifies which URL to limit the results to. As always, the k parameter contains the query itself. This is a simple customization to implement and I highly recommend it if you want to customize your contextual search results.
I am excited to be going back to Kansas City again this weekend to speak at SharePoint Saturday Kansas City. This is my third SharePoint Saturday in KC and I can’t wait to see old friends and make some new ones. I’ve got two talks this year: Beginning SharePoint Development for ASP.NET Developers and How the SharePoint BCS can change your life. These are some of my favorite talks to give and I’ve revamped them so they should be quite informative. I hope to see everyone there!
If you haven’t checked out the new NothingButSharePoint.com (NBSP), you should take a look. This new site combines articles from Jeremy Thake’s SharePointDevWiki.com, Joel Oleson’s SharePointJoel.com and Mark Miller’s EndUserSharePoint.com in one centralized location. I’m excited to have one of the first articles out there (even if did take me months to write :) ) about naming conventions in SharePoint. What I thought would be a simple article quickly turned out to be one of the longest posts I have ever written. I hope to get lots of feedback and expand on the concepts in a follow up article. Check it out today!
A Guide to Naming Conventions in SharePoint