In v10 of Azure Search SDK, I was able to specify exactly which fields to search in an index by taking advantage of SearchParameters class. In v11, I see there is SearchOptions, but the SearchFields parameter is get only. In v10, SearchFields has a setter.
How do I choose which fields to search on in v11?
You can call .Add() on the SearchFields property:
var options = new SearchOptions();
options.SearchFields.Add("field1");
options.SearchFields.Add("field2");
Or you can use C#'s list initializer syntax:
var options = new SearchOptions() { SearchFields = { "field1", "field2" } };
Example adapted from this GitHub issue.
Related
In an older JavaScript app I used keyword-query to search for document properties, and I could add the 'DlcDocID' field (Document id) to be retrieved.
I am currently developing an Spfx version of the app, and use pnp.sp.search to get document data. This way I can get the UniqueId and the DocId, but not the Document Id. How can I have this parameter included in the search results?
Extra:
I am using 1.3.11, and this code
pnp.sp.search(
{
Querytext:query,
RowLimit:rows,
StartRow:start,
SelectProperties: ["DocId"
, "UniqueId"
,"FileType"
,"ServerRedirectedEmbedURL"
, "ServerRedirectedPreviewURL"
,"LastModifiedTime"
,"Write"
,"Size"
,"SPWebUrl"
,"ParentLink"
,"Title"
,"HitHighlightedSummary"
,"Path"
,"Author"
,"LastModifiedTime"
,"DlcDocID"
],
But DlcDocID is never retrieved.
Looking at the docs, DlcDocID should be retrievable (it's queryable and retrievable by default). Have you tried using SearchQueryBuilder and selectProperties?
const q = SearchQueryBuilder().text(yourQuery).
.rowLimit(10).processPersonalFavorites.selectProperties('*', 'DlcDocID');
const results = await sp.search(q);
SearchQueryBuilder reference
The issue was that the pnp
SearchResult interface didn't have the DlcDocID in this version. Adding it solved the problem.
I am trying to build the lucene fulltext search with the wildcard expression to represent "Contains" /*.<Keyword>/*, but in the Buildparameter model which is provided by the Azure Search library does not have the search properties.
I am using
Documents.Search<T>(searchTerm, searchParam);
//where SearchTerm is the <typed key search> for ex "Nurs" and the result
//should be where all or any text contains "Nurs"
The Azure.Search.Models SearchParameter which i am using to build is where i Extended to create the new class to contain the Search field.
return new ExtentedSearchParameter
{
IncludeTotalResultCount = true,
SearchFields = new List<string>() {"FilterableTitle", "FilterableAlternativeTitle"},
Skip = (properties.Page - 1) * properties.Count,
Top = properties.Count,
Search=properties.SearchQuery,
QueryType = QueryType.Full ,
Select=new List<string>(){"FilterableTitle", "FilterableAlternativeTitle"},
OrderBy = properties.OrderByFields,
};
and in my application I am building the query like
if (string.IsNullOrWhiteSpace(returnProperties.FilterBy))
{
returnProperties.SearchQuery =$"FilterableTitle: /.*'{cleanSearchTerm.TrimStart('\"').TrimEnd('\"')}.*/' and FilterableAlternativeTitle:/.*'{cleanSearchTerm.TrimStart('\"').TrimEnd('\"')}.*/'";
}
When I am passing the searchparameter and the search term its not returning the result and its throwing an exception.
Instead of extending the SearchParameters class, you can pass your Lucene query as the searchText parameter to the Search method:
Documents.Search<T>(properties.SearchQuery, searchParam);
I am using OrmLite to call stored procedure that has optional parameters.
_dbConnection.SqlList<CustomerDTO>("sp_getcustomers #name", new { name = request.Name });
This statement is generating dynamic sql statement with #name as parameter. But I am not knowing how to pass null to this parameter, I tried using DBNull.Value but its not working.
Exception : The given key was not present in the dictionary is raised.
_dbConnection.SqlList<CustomerDTO>("sp_getcustomers #name", new { name = request.Name ?? System.Data.SqlTypes.SqlString.Null});
See these SqlProviderTests for examples of how to effectively make use of OrmLite's Sql* apis.
The right way to call it is with something like:
Db.SqlList<CustomerDTO>("EXEC sp_getcustomers #Name", new { request.Name });
Ormlite has a T4 file to generate C# functions equivalents for the SPs (for SqlServer); the generated files allows you to pass null values.
Support for null parameters in stored procedures was added in commit e6ef83a and released with version 3.9.56 of ServiceStack.OrmLite.
I've been checking ServiceStack's documentation, but I haven't found a way to do many to many relationships with ServiceStack.OrmLite, is it supported? Is there a workaround (without writing raw sql)?
I'd like to have something like this:
Article <- ArticleToTag -> Tag
Thanks!!
It's not implicitly handled automatically for you behind the scenes if that's what you mean? But as OrmLite is just a thin wrapper around ADO.NET interfaces anything is possible.
In OrmLite, by default every POCO maps 1:1 with a table. So if you wanted the table layout you would create it just as it looks in your database, e.g.
var article = new Article { ... };
var tag = new Tag { ... };
var articleTag = new ArticleTag { ArticleId = article.Id, TagId = tag.Id };
db.Insert(article, tag, articleTag);
Although you might want to take advantage of the built-in blobbing in OrmLite where any complex type just gets serialized and stored in a single text field. So you could do something like:
var article = { new Article { Tags = { "A","B","C" } };
Where Tags is just a List<string> and OrmLite will take care of transparently serializing it in the database field for you.
I am having trouble with a MOSS FulltextSqlQuery when attempting to filter People results on the Skills Managed Property using the CONTAINS predicate. Let me demonstrate:
A query with no filters returns the expected result:
SELECT AccountName, Skills
from scope()
where freetext(defaultproperties,'+Bob')
And ("scope" = 'People')
Result
Total Rows: 1
ACCOUNTNAME: MYDOMAIN\Bob
SKILLS: Numchucks | ASP.Net | Application Architecture
But when I append a CONTAINS predicate, I no longer get the expected result:
SELECT AccountName, Skills
from scope()
where freetext(defaultproperties,'+Bob')
And ("scope" = 'People')
And (CONTAINS(Skills, 'Numchucks'))
Result
Total Rows: 0
I do realize I can accomplish this using the SOME ARRAY predicate, but I would like to know why this is not working with the CONTAINS predicate for the Skills property. I have been successful using the CONTAINS predicate with a custom crawled property that is indicated as 'Multi-valued'. The Skills property (though it seems to be multi-valued) is not indicated as such on the Crawled Properties page in the SSP admin site:
http:///ssp/admin/_layouts/schema.aspx?ConsoleView=crawledPropertiesView&category=People
Anyone have any ideas?
So with the help of Mark Cameron (Microsoft SharePoint Developer Support), I figured out that certain managed properties have to be enabled for full text search using the ManagedProperty object model API by setting the FullTextQueriable property to true. Below is the method that solved this issue for me. It could be included in a Console app or as a Farm or Web Application scoped Feature Receiver.
using Microsoft.Office.Server;
using Microsoft.Office.Server.Search.Administration;
private void EnsureFullTextQueriableManagedProperties(ServerContext serverContext)
{
var schema = new Schema(SearchContext.GetContext(serverContext));
var managedProperties = new[] { "SKILLS", "INTERESTS" };
foreach (ManagedProperty managedProperty in schema.AllManagedProperties)
{
if (!managedProperties.Contains(managedProperty.Name.ToUpper()))
continue;
if (managedProperty.FullTextQueriable)
continue;
try
{
managedProperty.FullTextQueriable = true;
managedProperty.Update();
Log.Info(m => m("Successfully set managed property {0} to be FullTextQueriable", managedProperty.Name));
}
catch (Exception e)
{
Log.Error(m => m("Error updating managed property {0}", managedProperty.Name), e);
}
}
}
SELECT AccountName, Skills
from scope()
where freetext(defaultproperties,'+Bob')
And ("scope" = 'People')
And (CONTAINS(Skills, 'Numchucks*'))
use the * in the end.
You also have a few more options to try:
The following list identifies
additional query elements that are
supported only with SQL search syntax
using the FullTextSqlQuery class:
FREETEXT()
CONTAINS()
LIKE
Source