Remove mention of type from Getting Started docs (#5187)

This commit removes the mention of document types
from the Getting Started docs.

Author: russcam

docs/client-concepts/high-level/getting-started.asciidoc

@@ -112,8 +112,8 @@ var asyncIndexResponse = await client.IndexDocumentAsync(person); <2>
 NOTE: All methods available within NEST are exposed as both synchronous and asynchronous versions,
 with the latter using the idiomatic *Async suffix on the method name.
 
-This will index the document to the endpoint `/people/person/1`. NEST is smart enough to infer the
-type from the Person CLR type as well as infer the id for the document by looking for an `Id` property on the POCO. Take a look
+This will index the document to the endpoint `/people/_doc/1`. NEST is smart enough to infer the
+the id for the document by looking for an `Id` property on the POCO. Take a look
 at <<ids-inference,Ids inference>> to see other ways in which NEST can be configured to infer an id for a document. The default index configured
 on `ConnectionSettings` has been used as the index name for the request.
 
@@ -141,7 +141,7 @@ var searchResponse = client.Search<Person>(s => s
 var people = searchResponse.Documents;
 ----
 
-`people` now holds the first ten people whose first name is Martijn. The search endpoint for this query is
+`people` now holds the first ten people whose first name matches Martijn. The search endpoint for this query is
 `/people/_search` and the index (`"people"`) has been determined from
 
 . the default index on `ConnectionSettings`
@@ -151,7 +151,7 @@ var people = searchResponse.Documents;
 which generates a request to the search endpoint `/people/_search`, using the default index specified on `ConnectionSettings` as the index
 in the search request.
 
-Similarly, a search can be performed for `person` types in all indices with `.AllIndices()`
+Similarly, a search can be performed in all indices with `.AllIndices()`
 
 [source,csharp]
 ----
@@ -168,27 +168,9 @@ var searchResponse = client.Search<Person>(s => s
 );
 ----
 
-which generates a request to the search endpoint `/_search`, taking the `person` type from the generic type parameter on the search
-method.
+which generates a request to the search endpoint `/_search`.
 
-Both `.AllTypes()` and `.AllIndices()` can be provided to perform a search across _all_ types in _all_ indices, generating a request to `/_search`
-
-[source,csharp]
-----
-var searchResponse = await client.SearchAsync<Person>(s => s
-    .AllIndices()
-    .From(0)
-    .Size(10)
-    .Query(q => q
-         .Match(m => m
-            .Field(f => f.FirstName)
-            .Query("Martijn")
-         )
-    )
-);
-----
-
-Single or multiple index and type names can be provided in the request;
+Single or multiple index names can be provided in the request;
 see the documentation on <<indices-paths,Indices paths>> and <<document-paths,Document paths>>, respectively.
 
 All of the search examples so far have used NEST's Fluent API which uses lambda expressions to construct a query with a structure
@@ -227,7 +209,7 @@ Using the low level client via the `.LowLevel` property means you can get with t
 
 . Use the high level client
 
-. Use the low level client where it makes sense, taking advantage of all the strong types within NEST and using the JSON.Net based
+. Use the low level client where it makes sense, taking advantage of all the strong types within NEST, and its
 serializer for deserialization.
 
 Here's an example
@@ -252,7 +234,7 @@ var responseJson = searchResponse;
 ----
 
 Here, the query is represented as an anonymous type, but the body of the response is a concrete
-implementation of the same response type returned from NEST.
+implementation of the same response type returned from the high level client, NEST.
 
 --
 

docs/client-concepts/high-level/inference/document-paths.asciidoc

@@ -16,7 +16,7 @@ please modify the original csharp file found at the link and submit the PR with
 === Document paths
 
 Many APIs in Elasticsearch describe a path to a document. In NEST, besides generating a constructor that takes
-and Index, Type and Id separately, we also generate a constructor that allows you to describe the path
+an Index and Id separately, we also generate a constructor that allows you to describe the path
 to your document more succinctly using a an instance of the `DocumentPath<T>` type.
 
 ==== Creating new instances 
@@ -30,7 +30,7 @@ Expect("project").WhenSerializing(path.Index);
 Expect(1).WhenSerializing(path.Id);
 ----
 
-You can still override the inferred index and type name
+You can still override the inferred index name
 
 [source,csharp]
 ----
@@ -65,7 +65,7 @@ Expect("project").WhenSerializing(path.Index);
 Expect("hello-world").WhenSerializing(path.Id);
 ----
 
-You can still override the inferred index and type name
+You can still override the inferred index name
 
 [source,csharp]
 ----
@@ -95,7 +95,7 @@ we can see an example of how `DocumentPath` helps your describe your requests mo
 [source,csharp]
 ----
 var request = new IndexRequest<Project>(2) { Document = project };
-request = new IndexRequest<Project>(project) { };
+request = new IndexRequest<Project>(project);
 ----
 
 when comparing with the full blown constructor and passing document manually,
@@ -110,3 +110,5 @@ request = new IndexRequest<Project>(IndexName.From<Project>(), 2)
 };
 ----
 
+Much more verbose, wouldn't you agree?
+

tests/Tests/ClientConcepts/HighLevel/GettingStarted.doc.cs

@@ -118,8 +118,8 @@ public async Task Indexing()
 		 * NOTE: All methods available within NEST are exposed as both synchronous and asynchronous versions,
 		 * with the latter using the idiomatic *Async suffix on the method name.
 		 *
-		 * This will index the document to the endpoint `/people/person/1`. NEST is smart enough to infer the
-		 * type from the Person CLR type as well as infer the id for the document by looking for an `Id` property on the POCO. Take a look
+		 * This will index the document to the endpoint `/people/_doc/1`. NEST is smart enough to infer the
+		 * the id for the document by looking for an `Id` property on the POCO. Take a look
 		 * at <<ids-inference,Ids inference>> to see other ways in which NEST can be configured to infer an id for a document. The default index configured
 		 * on `ConnectionSettings` has been used as the index name for the request.
 		 *
@@ -148,17 +148,16 @@ public void Searching()
 		}
 
 		/**
-		 * `people` now holds the first ten people whose first name is Martijn. The search endpoint for this query is
+		 * `people` now holds the first ten people whose first name matches Martijn. The search endpoint for this query is
 		 * `/people/_search` and the index (`"people"`) has been determined from
 		 *
 		 * . the default index on `ConnectionSettings`
 		 * . the `Person` generic type parameter on the search.
 		 *
-		 *
 		 * which generates a request to the search endpoint `/people/_search`, using the default index specified on `ConnectionSettings` as the index
 		 * in the search request.
 		 *
-		 * Similarly, a search can be performed for `person` types in all indices with `.AllIndices()`
+		 * Similarly, a search can be performed in all indices with `.AllIndices()`
 		 */
 		public void SearchingAllIndices()
 		{
@@ -176,28 +175,9 @@ public void SearchingAllIndices()
 		}
 
 		/**
-		 * which generates a request to the search endpoint `/_search`, taking the `person` type from the generic type parameter on the search
-		 * method.
+		 * which generates a request to the search endpoint `/_search`.
 		 *
-		 * Both `.AllTypes()` and `.AllIndices()` can be provided to perform a search across _all_ types in _all_ indices, generating a request to `/_search`
-		 */
-		public async Task SearchingAllIndicesAndAllTypes()
-		{
-			var searchResponse = await client.SearchAsync<Person>(s => s
-				.AllIndices()
-				.From(0)
-				.Size(10)
-				.Query(q => q
-					 .Match(m => m
-						.Field(f => f.FirstName)
-						.Query("Martijn")
-					 )
-				)
-			);
-		}
-
-		/**
-		 * Single or multiple index and type names can be provided in the request;
+		 * Single or multiple index names can be provided in the request;
 		 * see the documentation on <<indices-paths,Indices paths>> and <<document-paths,Document paths>>, respectively.
 		 *
 		 * All of the search examples so far have used NEST's Fluent API which uses lambda expressions to construct a query with a structure
@@ -234,7 +214,7 @@ public async Task ObjectInitializerSyntax()
 		 * Using the low level client via the `.LowLevel` property means you can get with the best of both worlds:
 		 *
 		 * . Use the high level client
-		 * . Use the low level client where it makes sense, taking advantage of all the strong types within NEST and using the JSON.Net based
+		 * . Use the low level client where it makes sense, taking advantage of all the strong types within NEST, and its
 		 * serializer for deserialization.
 		 *
 		 * Here's an example
@@ -260,7 +240,7 @@ public void SearchingWithTheLowLevelClient()
 		}
 		/**
 		 * Here, the query is represented as an anonymous type, but the body of the response is a concrete
-		 * implementation of the same response type returned from NEST.
+		 * implementation of the same response type returned from the high level client, NEST.
 		 * --
 		 */
 

tests/Tests/ClientConcepts/HighLevel/Inference/DocumentPaths.doc.cs

@@ -16,7 +16,7 @@ public class DocumentPaths
 		 * === Document paths
 		 *
 		 * Many APIs in Elasticsearch describe a path to a document. In NEST, besides generating a constructor that takes
-		 * and Index, Type and Id separately, we also generate a constructor that allows you to describe the path
+		 * an Index and Id separately, we also generate a constructor that allows you to describe the path
 		 * to your document more succinctly using a an instance of the `DocumentPath<T>` type.
 		 */
 
@@ -29,7 +29,7 @@ [U] public void FromId()
 			Expect("project").WhenSerializing(path.Index);
 			Expect(1).WhenSerializing(path.Id);
 
-			/** You can still override the inferred index and type name*/
+			/** You can still override the inferred index name*/
 			path = new DocumentPath<Project>(1).Index("project1");
 			Expect("project1").WhenSerializing(path.Index);
 
@@ -52,7 +52,7 @@ [U] public void FromObject()
 			Expect("project").WhenSerializing(path.Index);
 			Expect("hello-world").WhenSerializing(path.Id);
 
-			/** You can still override the inferred index and type name*/
+			/** You can still override the inferred index name*/
 			path = new DocumentPath<Project>(project).Index("project1");
 			Expect("project1").WhenSerializing(path.Index);
 
@@ -72,7 +72,7 @@ [U] public void UsingWithRequests()
 
 			/** we can see an example of how `DocumentPath` helps your describe your requests more tersely */
 			var request = new IndexRequest<Project>(2) { Document = project };
-			request = new IndexRequest<Project>(project) { };
+			request = new IndexRequest<Project>(project);
 
 			/** when comparing with the full blown constructor and passing document manually,
 			* `DocumentPath<T>`'s benefits become apparent. Compare the following request that doesn't
@@ -82,9 +82,9 @@ [U] public void UsingWithRequests()
 			{
 				Document = project
 			};
-			/**
-			 * Much more verbose, wouldn't you agree?
-			 */
 		}
+		/**
+		 * Much more verbose, wouldn't you agree?
+		 */
 	}
 }