Merge branch 'master' of github.com:elastic/elasticsearch-net

Author: russcam

docs/aggregations/writing-aggregations.asciidoc

@@ -228,6 +228,7 @@ return s => s
         );
 ----
 <1> a list of aggregation functions to apply
+
 <2> Using LINQ's `Aggregate()` function to accumulate/apply all of the aggregation functions
 
 [[handling-aggregate-response]]
@@ -259,5 +260,6 @@ var maxPerChild = childAggregation.Max("max_per_child");
 maxPerChild.Should().NotBeNull(); <2>
 ----
 <1> Do something with the average per child. Here we just assert it's not null
+
 <2> Do something with the max per child. Here we just assert it's not null
 

docs/client-concepts/certificates/working-with-certificates.asciidoc

@@ -80,7 +80,7 @@ public class AllowAllCertificatesCluster : SslAndKpiXPackCluster
 If your client application has access to the public CA certificate locally, Elasticsearch.NET and NEST ship with some handy helpers
 that can assert that a certificate the server presents is one that came from the local CA.
 
-If you use X-Pack's {ref_current}/certutil.html[+certutil+ tool] to generate SSL certificates, the generated node certificate
+If you use X-Pack's {ref_current}/certutil.html`certutil` tool] to generate SSL certificates, the generated node certificate
 does not include the CA in the certificate chain, in order to cut down on SSL handshake size. In those case you can use`CertificateValidations.AuthorityIsRoot` and pass it your local copy of the CA public key to assert that
 the certificate the server presented was generated using it
 
@@ -115,7 +115,7 @@ the local CA certificate is part of the chain that was used to generate the serv
 ==== Client Certificates
 
 X-Pack also allows you to configure a {xpack_current}/pki-realm.html[PKI realm] to enable user authentication
-through client certificates. The {ref_current}/certutil.html[+certutil+ tool] included with X-Pack allows you to
+through client certificates. The {ref_current}/certutil.html`certutil` tool] included with X-Pack allows you to
 generate client certificates as well and assign the distinguished name (DN) of the
 certificate to a user with a certain role.
 

docs/client-concepts/connection-pooling/exceptions/unexpected-exceptions.asciidoc

@@ -58,8 +58,11 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> set up a cluster with 10 nodes
+
 <2> where node 2 on port 9201 always throws an exception
+
 <3> The first call to 9200 returns a healthy response
+
 <4> ...but the second call, to 9201, returns a bad response
 
 Sometimes, an unexpected exception happens further down in the pipeline. In this scenario, we
@@ -98,7 +101,9 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> calls on 9200 set up to throw a `WebException`
+
 <2> calls on 9201 set up to throw an `Exception`
+
 <3> Assert that the audit trail for the client call includes the bad response from 9200 and 9201
 
 An unexpected hard exception on ping and sniff is something we *do* try to recover from and failover to retrying on the next node.
@@ -143,6 +148,8 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> `InnerException` is the exception that brought the request down
+
 <2> The hard exception that happened on ping is still available though
+
 <3> An exception can be hard to relate back to a point in time, so the exception is also available on the audit trail
 

docs/client-concepts/connection-pooling/exceptions/unrecoverable-exceptions.asciidoc

@@ -81,6 +81,7 @@ var audit = new Auditor(() => Framework.Cluster
 );
 ----
 <1> Always succeed on ping
+
 <2> ...but always fail on calls with a 401 Bad Authentication response
 
 Now, let's make a client call. We'll see that the first audit event is a successful ping
@@ -101,7 +102,9 @@ audit = await audit.TraceElasticsearchException(
 );
 ----
 <1> First call results in a successful ping
+
 <2> Second call results in a bad response
+
 <3> The reason for the bad response is Bad Authentication
 
 When a bad authentication response occurs, the client attempts to deserialize the response body returned;
@@ -135,6 +138,7 @@ audit = await audit.TraceElasticsearchException(
 );
 ----
 <1> Always return a 401 bad response with a HTML response on client calls
+
 <2> Assert that the response body bytes are null
 
 Now in this example, by turning on `DisableDirectStreaming()` on `ConnectionSettings`, we see the same behaviour exhibited
@@ -169,5 +173,6 @@ audit = await audit.TraceElasticsearchException(
 );
 ----
 <1> Response bytes are set on the response
+
 <2> Assert that the response contains `"nginx/"`
 

docs/client-concepts/connection-pooling/request-overrides/disable-sniff-ping-per-request.asciidoc

@@ -65,8 +65,11 @@ audit = await audit.TraceCalls(
 );
 ----
 <1> disable sniffing
+
 <2> first call is a successful ping
+
 <3> sniff on startup call happens here, on the second call
+
 <4> No sniff on startup again
 
 Now, let's disable pinging on the request 
@@ -90,6 +93,7 @@ audit = await audit.TraceCall(
 );
 ----
 <1> disable ping
+
 <2> No ping after sniffing
 
 Finally, let's demonstrate disabling both sniff and ping on the request 
@@ -111,5 +115,6 @@ audit = await audit.TraceCall(
 );
 ----
 <1> diable ping and sniff
+
 <2> no ping or sniff before the call
 

docs/client-concepts/connection-pooling/round-robin/skip-dead-nodes.asciidoc

@@ -140,7 +140,9 @@ await audit.TraceCalls(
 );
 ----
 <1> The first call goes to 9200 which succeeds
+
 <2> The 2nd call does a ping on 9201 because its used for the first time. It fails so we wrap over to node 9202
+
 <3> The next call goes to 9203 which fails so we should wrap over
 
 A cluster with 2 nodes where the second node fails on ping 
@@ -190,5 +192,6 @@ await audit.TraceCalls(
 );
 ----
 <1> All the calls fail
+
 <2> After all our registered nodes are marked dead we want to sample a single dead node each time to quickly see if the cluster is back up. We do not want to retry all 4 nodes
 

docs/client-concepts/connection-pooling/sniffing/role-detection.asciidoc

@@ -138,6 +138,7 @@ var audit = new Auditor(() => Framework.Cluster
 };
 ----
 <1> Before the sniff, assert we only see three master only nodes
+
 <2> After the sniff, assert we now know about the existence of 20 nodes.
 
 After the sniff has happened on 9200 before the first API call, assert that the subsequent API
@@ -218,7 +219,9 @@ var audit = new Auditor(() => Framework.Cluster
 };
 ----
 <1> for testing simplicity, disable pings
+
 <2> We only want to execute API calls to nodes in rack_one
+
 <3> After sniffing on startup, assert that the pool of nodes that the client will execute API calls against only contains the three nodes that are in `rack_one`
 
 With the cluster set up, assert that the sniff happens on 9200 before the first API call
@@ -295,6 +298,8 @@ await audit.TraceUnexpectedElasticsearchException(new ClientCall
 });
 ----
 <1> The audit trail indicates a sniff for the very first time on startup
+
 <2> The sniff succeeds because the node predicate is ignored when sniffing
+
 <3> when trying to do an actual API call however, the predicate prevents any nodes from being attempted
 

docs/client-concepts/high-level/analysis/writing-analyzers.asciidoc

@@ -103,6 +103,7 @@ var createIndexResponse = client.CreateIndex("my-index", c => c
 );
 ----
 <1> Pre-defined list of English stopwords within Elasticsearch
+
 <2> Use the `standard_english` analyzer configured
 
 [source,javascript]
@@ -268,6 +269,7 @@ var createIndexResponse = client.CreateIndex("questions", c => c
 );
 ----
 <1> Use an analyzer at index time that strips HTML tags
+
 <2> Use an analyzer at search time that does not strip HTML tags
 
 With this in place, the text of a question body will be analyzed with the `index_question` analyzer

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

@@ -107,6 +107,7 @@ var indexResponse = client.IndexDocument(person); <1>
 var asyncIndexResponse = await client.IndexDocumentAsync(person); <2>
 ----
 <1> synchronous method that returns an `IIndexResponse`
+
 <2> asynchronous method that returns a `Task<IIndexResponse>` that can be awaited
 
 NOTE: All methods available within NEST are exposed as both synchronous and asynchronous versions,

docs/client-concepts/high-level/inference/field-inference.asciidoc

@@ -412,7 +412,7 @@ for property `C` on `B`
 ----
 var newConnectionSettings = TestClient.CreateSettings(modifySettings: s => s
     .DefaultMappingFor<A>(m => m
-        .Rename(p => p.C, "d")
+        .PropertyName(p => p.C, "d")
     )
 );
 var newClient = new ElasticClient(newConnectionSettings);
@@ -440,13 +440,10 @@ fieldNameOnB.Should().Be("c.name");
 
 To wrap up, the precedence in which field names are inferred is:
 
-. A hard rename of the property on connection settings using `.Rename()`
-
-. A NEST property mapping
-
-. Ask the serializer if the property has a verbatim value e.g it has an explicit JsonProperty attribute.
-
-. Pass the MemberInfo's Name to the DefaultFieldNameInferrer, which by default camelCases
+1) A hard rename of the property on connection settings using `.PropertyName()`
+2) A NEST PropertyNameAttribute
+3) Ask the serializer if the property has a verbatim value, e.g it has a JsonPropertyAttribute.
+4) Pass the MemberInfo's Name to the DefaultFieldNameInferrer, which by default will camelCase
 
 The following example class will demonstrate this precedence
 
@@ -474,11 +471,16 @@ class Precedence
     public string DefaultFieldNameInferrer { get; set; } <6>
 }
 ----
-<1> Even though this property has a NEST property mapping _and_ a `JsonProperty` attribute, We are going to provide a hard rename for it on ConnectionSettings later that should win.
-<2> This property has both a NEST attribute and property and a `JsonProperty`, NEST should win.
-<3> This property has both a NEST property and a `JsonProperty`, NEST should win.
-<4> We should take the json property into account by itself
+<1> Even though this property has various attributes applied we provide an override on ConnectionSettings later that takes precedence.
+
+<2> Has a `TextAttribute`, `PropertyNameAttribute` and a `JsonPropertyAttribute` - the `TextAttribute` takes precedence.
+
+<3> Has both a `PropertyNameAttribute` and a `JsonPropertyAttribute` - the `PropertyNameAttribute` takes precedence.
+
+<4> `JsonPropertyAttribute` takes precedence.
+
 <5> This property we are going to hard code in our custom serializer to resolve to ask.
+
 <6> We are going to register a DefaultFieldNameInferrer on ConnectionSettings that will uppercase all properties.
 
 Here we create a custom serializer that renames any property named `AskSerializer` to `ask`
@@ -496,15 +498,15 @@ class CustomPropertyMappingProvider : PropertyMappingProvider
 }
 ----
 
-Here we provide an explicit rename of a property on `ConnectionSettings` using `.Rename()`
+Here we provide an explicit rename of a property on `ConnectionSettings` using `.PropertyName()`
 and all properties that are not mapped verbatim should be uppercased
 
 [source,csharp]
 ----
 var usingSettings = WithConnectionSettings(s => s
 
     .DefaultMappingFor<Precedence>(m => m
-        .Rename(p => p.RenamedOnConnectionSettings, "renamed")
+        .PropertyName(p => p.RenamedOnConnectionSettings, "renamed")
     )
     .DefaultFieldNameInferrer(p => p.ToUpperInvariant())
 ).WithPropertyMappingProvider(new CustomPropertyMappingProvider());
@@ -555,7 +557,7 @@ Inherited properties can be ignored and renamed just as one would expect
 ----
 var usingSettings = WithConnectionSettings(s => s
     .DefaultMappingFor<Child>(m => m
-        .Rename(p => p.Description, "desc")
+        .PropertyName(p => p.Description, "desc")
         .Ignore(p => p.IgnoreMe)
     )
 );