Desktop Search SDK FAQ: What column names can I ask for?
So our (beta) SDK sample includes a sizeable list of column names that you can ask for from the indexer (in the QueryBuilder.cs file)… but it’s far from a full list. These are the string constants that you pass to ExecuteQuery in the second parameter (and also you pass one of them as the third parameter to sort by). ExecuteQuery works like this:
_Recordset resultSet = foo.ExecuteQuery(“a query to search for“, “DocTitle, DocAuthor, Url“, “DocTitle“, null)
Let’s break those down:
Param 1: The first parameter is the query string, which is usually the user’s input. Now… you can take more control by modifying the user’s input. For example, if I’m building a music organizer, I might want to do this:
string foo = userInput + “ kind:music“;
Or if you’re like me (and use obscure file formats), userInput + “ fileext:(wma OR mp3 OR shn OR flac OR ogg OR mp4 OR aac)“ and so on =)
Param 2: This is the list of columns you want back – formatted as a comma delimited string. If you pass invalid column names or an improperly formatted string, the COM interface will throw an exception (so validate your input!). This is the SELECT portion of the SQL expression.
Param 3: This is the column you want the results ordered by. This directly becomes the ORDER BY clause so you’ll need to pass it in as “RecievedDate DESC” or “ReceivedDate ASC”. This value must be explicitly set to null (or Nothing in vb) if you don’t want the results sorted. Due to a bug in 2.5 passing an empty string (“”) will cause the method to fail.
Param 4: This is any optional constraint you want appended to the SQL expressions WHERE clause. Why do you need this? It let’s you filter the results to a particular type without have to append the AQS expression of “type:email” to the users query. To constrain the results to email you’d pass in “Contains(PerceivedType,’email’)”. This value must also be explicitly set to null if you don’t want any additional constraint applied. Due to a bug in 2.5 passing an empty string (“”) will cause the method to fail.
So how do you know what to send in the second and third parameters?
This is COMPLETEY UNSUPPORTED and all column names are SUBJECT TO CHANGE (and probably will) in future releases. Once again, our SDK and API are considered BETA components and are subject to change. Changing the registry can have very adverse effects on your system and do not attempt to use regedit unless you know what you’re doing.
We have the ability to log queries for support/diagnostic purposes by adding a DWORD to the registry named WriteLog under the key HKCU\Software\Microsoft\MSN Apps\DS and setting it to 1. As it turns out, the log that’s created is especially useful for developers. Once you’ve enabled logging, we log the SQL that is generated for every query in a file in your root path called “query.txt“
By running a query with this logging enabled, you can see the SQL that is generated. The SELECT statement will include all the columns that the UI asked for.
As I said above, the column names are probably going to change in future releases. While we do strive to keep from breaking things whenever possible, we have intentionally not documented these column names because we’re not ready to say that they’re final. Because of this please plan on future WDS releases changing these interfaces and the column names. No one here wants to make working with our stuff difficult for you, but for a fairly new product like ours we’re not yet comfortable with the burden that comes with promising future compatability on our current APIs – and we wouldn’t be repeating this disclaimer over and over if it wasn’t a serious concern for us.
Comments are closed.