Set up references

- [Instructor] So first thing we need to do is go to appSettings inside App.config and add certain values that we need. So we can add a few different kinds of keys, one could be the CaztonSearchName. And the value, as you know, is cazton. The next thing we want to do is we want to get the AdminKey.

And then we can also use a QueryApiKey. In order to get that key we go back to the portal, click to copy, and do the same thing for the Query key. Go back to Program.cs.

The first thing to do would be to take the searchServiceName and use ConfigurationManager. In order to make that work we're going to have to add a reference. System.Configuration.

Once we have that we can say Control + . and now we can go choose AppSettings and add the names of those settings. So we have the searchServiceName.

And then we have the AdminKey. And then we have the QueryApiKey.

That's all we need. Now it's time to get the NuGet Package. We're going to look for Azure.Search. And this is the one we want. We've got the latest stable version of 3.0.4. We can say Install, say OK, Accept the License.

First thing we'll end up using is SearchServiceClient and in order to resolve this we'll use ctrl + .. As you can see, it was able to add the reference. We'll initialize the SearchServiceClient with the searchServiceName. And then we'll initialize the Credentials and in this case we'll end up using the adminKey.

We'll need to make these keys static, so we can use them inside void Main. And that key is the search client, the serviceClient for us that we can use now to add an index. So the first thing we'll like to do is say well, if the serviceClient has Indexers and then make sure that if this particular index already exists then we want to make sure that we delete it. And in this case you will notice that that is not valid, but since we're going to be working with the same data set over and over again we want to make sure that we don't get into exceptions, especially for this course.

So as you can see, we've deleted the index, if it exists. The next thing would be to define the index and this would be the index definition, or I could also say accountIndexDefinition. And that's part of Microsoft.Azure.Search.Model, so you will have to resolve that reference again and you might not find (mumbling) on it the first time you try to code this.

Now we can give a Name, in this case it's going to be accounts. And then we can say Fields and actually tell it to build the Field for our type. We don't really have an account type, so we're going to create this from scratch. So for now we'll go ahead and comment this code. Just looking at the References you're better off getting some other References.

First thing would be a NuGet Package, which is Newtonsoft.Json. It's by far the most popular package I think on NuGet. Another package which you might want to consider getting could be Microsoft.Extensions.Configuration.

And then Microsoft.Extensions.Configuration.Json. Now that we have both of these we'll right-click and Add a Class. I'm going to call it Account, giving it the same name as the index that we're trying to create.

Make sure it's public. Next thing I'd like to do is add a Serializable attribute, except this is just a little bit different than the regular Serializable attribute you've been using. This is the one that says SerializablePropertyNamesAsCamelCase. This way we don't have go to every single property and make it a camel case. A bit of a typo there, and then do Control + . and you can see this is coming from Azure.Search.Models.

First thing would be our key, which happens to be Account_Number. If it's easier, what you might want to do is copy this. Say Shift + End, and then say Control + C, and then bring it over to Account.cs and just paste it as it is, and then comment it. Now we know that the second property is balance and then we have lastname, firstname, and other properties.

So we know it's string, but we have to make sure that we give it another attribute, which in this case could be the key attribute, and that's inside DataAnnotations.Key. Now for this particular value to work we're going to have to add another Reference. And that's it.

So now we see this should work. And we can also add other attributes, for example, IsFilterable. When we do that we're going to have to resolve the reference, Control + ., using Microsoft.Azure.Search. Let's go ahead and add the other properties. The next one would be balance. As you can see, it's a double. And it may not be required, even though we have our data for this you can also go ahead and add a question mark, that will make it a nullable property.

And as you can see, every property could be filterable. Even though it's double it's a good idea to add IsFilterable. Now can we use this to sort? We, of course, can. So I would make it IsSortable and then maybe we might have facets, which could be categories. We could be, like if the balance is between 100, 200,000 that's a different facet and if it's between 100,000 to a million dollars it's a difference facet. Same way, we can do other properties. As you can see, we have FirstName, LastName, and quite a few other properties here.

I'm just going to copy and paste a few of these, so we don't have to type this with hand. And then just go make some changes. So we have FirstName, we have LastName, and then we had Age, except Age happens to be an integer. And the next one was Address. And in this case it's just an address line one, so it's a string, otherwise you would have an address object. And then you have employer and then you have email and city and state.

This is just a one time setup and after that things should be much faster. And next what we could do is add the attributes that are missing. So where you have something like FirstName it could also mean that we could make it searchable, since it's a string, at the same time it could be a very good candidate for full tag search. We also want to make it filterable.

And then sometimes you might want to sort the entire list just by the FirstName or the LastName. Keep in mind using IsSearchable will bloat the index, so you should only do it for the properties that you need to do a full tag search on. And then we can have an Age. Of course, Age can not be IsSearchable, so we'll make this IsFilterable and IsFacetable. You can always have a situation where you want to categorize data by age, people who are, kids could be in a different category, teens could be in a different category, adults and senior citizens could be in completely different category.

And then if you have an Address and you might need to search for an Address, it's probably a good idea to use IsSearchable. And then something like an email we can make it IsFilterable and probably that's it. For an Employer it could be anything, it could be part of a facet, if we're going by the Employer.

Now we can always search using a City, sort using a City, and also filter using a City. And I would do the same exact thing for State. Now this particular class literally is our schema for our index.