Skip to content

Commit a55e258

Browse files
committed
Add parent-child relationships to documentation
1 parent 1ad5adf commit a55e258

File tree

12 files changed

+622
-249
lines changed

12 files changed

+622
-249
lines changed

docs/aggregations/metric/geo-centroid/geo-centroid-aggregation-usage.asciidoc

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -58,3 +58,11 @@ foreach (var bucket in projects.Buckets)
5858
}
5959
----
6060

61+
[source,csharp]
62+
----
63+
response.ShouldBeValid();
64+
var centroid = response.Aggregations.GeoCentroid("centroid");
65+
centroid.Should().NotBeNull();
66+
centroid.Count.Should().Be(0);
67+
----
68+

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

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -80,7 +80,7 @@ public class AllowAllCertificatesCluster : SslAndKpiXPackCluster
8080
If your client application has access to the public CA certificate locally, Elasticsearch.NET and NEST ship with some handy helpers
8181
that can assert that a certificate the server presents is one that came from the local CA.
8282

83-
If you use X-Pack's `certgen` tool to {xpack_current}/ssl-tls.html[generate SSL certificates], the generated node certificate
83+
If you use X-Pack's {ref_current}/certutil.html`certutil` tool] to generate SSL certificates, the generated node certificate
8484
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
8585
the certificate the server presented was generated using it
8686

@@ -115,16 +115,16 @@ the local CA certificate is part of the chain that was used to generate the serv
115115
==== Client Certificates
116116

117117
X-Pack also allows you to configure a {xpack_current}/pki-realm.html[PKI realm] to enable user authentication
118-
through client certificates. The `certgen` tool included with X-Pack allows you to
119-
{ref_current}/certgen.html[generate client certificates as well] and assign the distinguished name (DN) of the
118+
through client certificates. The {ref_current}/certutil.html`certutil` tool] included with X-Pack allows you to
119+
generate client certificates as well and assign the distinguished name (DN) of the
120120
certificate to a user with a certain role.
121121

122-
certgen by default only generates a public certificate `.cer`) and a private key `.key`. To authenticate with client certificates, you need to present both
122+
By default, the `certutil` tool only generates a public certificate `.cer`) and a private key `.key`. To authenticate with client certificates, you need to present both
123123
as one certificate. The easiest way to do this is to generate a `pfx` or `p12` file from the `.cer` and `.key`
124124
and attach these to requests using `new X509Certificate(pathToPfx)`.
125125

126126
If you do not have a way to run `openssl` or `Pvk2Pfx` to do this as part of your deployments the clients ships with a handy helper to generate one
127-
on the fly by passing the paths to the `.cer` and `.key` files that `certgen` outputs. Sadly, this functonality is not available on .NET Core because
127+
on the fly by passing the paths to the `.cer` and `.key` files that `certutil` outputs. Sadly, this functonality is not available on .NET Core because
128128
the `PublicKey` property cannot be set on the crypto service provider that is used to generate the `pfx` file at runtime.
129129

130130
You can set Client Certificates to use on all connections on `ConnectionSettings`

docs/client-concepts/connection-pooling/sniffing/on-connection-failure.asciidoc

Lines changed: 16 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -175,19 +175,29 @@ var audit = new Auditor(() => Framework.Cluster
175175
.Settings(s => s.SniffOnStartup(false))
176176
);
177177
178-
Action<Audit, string, int> hostAssert = (a, host, expectedPort) =>
178+
void HostAssert(Audit a, string host, int expectedPort)
179179
{
180180
a.Node.Uri.Host.Should().Be(host);
181181
a.Node.Uri.Port.Should().Be(expectedPort);
182-
};
182+
}
183+
void SniffUrlAssert(Audit a, string host, int expectedPort)
184+
{
185+
HostAssert(a, host, expectedPort);
186+
var sniffUri = new UriBuilder(a.Node.Uri)
187+
{
188+
Path = RequestPipeline.SniffPath,
189+
Query = "?flat_settings=true&timeout=2s"
190+
}.Uri;
191+
sniffUri.PathEquals(a.Path, nameof(SniffUrlAssert));
192+
}
183193
184194
audit = await audit.TraceCalls(
185195
new ClientCall {
186-
{ PingFailure, a => hostAssert(a, "localhost", 9200)},
196+
{ PingFailure, a => HostAssert(a, "localhost", 9200)},
187197
{ SniffOnFail },
188-
{ SniffSuccess, a => hostAssert(a, "localhost", 9200)},
189-
{ PingSuccess, a => hostAssert(a, "10.0.12.1", 9200)},
190-
{ HealthyResponse, a => hostAssert(a, "10.0.12.1", 9200)},
198+
{ SniffSuccess, a => SniffUrlAssert(a, "localhost", 9200)},
199+
{ PingSuccess, a => HostAssert(a, "10.0.12.1", 9200)},
200+
{ HealthyResponse, a => HostAssert(a, "10.0.12.1", 9200)},
191201
{ pool => pool.Nodes.Count.Should().Be(10) } <1>
192202
}
193203
);
Lines changed: 192 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,192 @@
1+
:ref_current: https://www.elastic.co/guide/en/elasticsearch/reference/master
2+
3+
:github: https://github.com/elastic/elasticsearch-net
4+
5+
:nuget: https://www.nuget.org/packages
6+
7+
////
8+
IMPORTANT NOTE
9+
==============
10+
This file has been generated from https://github.com/elastic/elasticsearch-net/tree/master/src/Tests/ClientConcepts/HighLevel/Inference/RoutingInference.doc.cs.
11+
If you wish to submit a PR for any spelling mistakes, typos or grammatical errors for this file,
12+
please modify the original csharp file found at the link and submit the PR with that change. Thanks!
13+
////
14+
15+
[[routing-inference]]
16+
=== Routing inference
17+
18+
==== Implicit conversion
19+
20+
You can always create a routing explicitly by relying on the implicit conversion from the following types
21+
22+
* `Int32`
23+
24+
* `Int64`
25+
26+
* `String`
27+
28+
* `Guid`
29+
30+
Methods and Properties that take an `Routing` can be passed any of these types and it will be implicitly
31+
converted to an instance of `Routing`
32+
33+
[source,csharp]
34+
----
35+
Routing routingFromInt = 1;
36+
Routing routingFromLong = 2L;
37+
Routing routingFromString = "hello-world";
38+
Routing routingFromGuid = new Guid("D70BD3CF-4E38-46F3-91CA-FCBEF29B148E");
39+
40+
Expect(1).WhenSerializing(routingFromInt);
41+
Expect(2).WhenSerializing(routingFromLong);
42+
Expect("hello-world").WhenSerializing(routingFromString);
43+
Expect("d70bd3cf-4e38-46f3-91ca-fcbef29b148e").WhenSerializing(routingFromGuid);
44+
----
45+
46+
==== Inferring from a type
47+
48+
The real power of the `Routing` is in the inference rules (the default inferred routing for an object will be null).
49+
Lets look at an example of this given the following POCO:
50+
51+
[source,csharp]
52+
----
53+
class MyDTO
54+
{
55+
public Guid Routing { get; set; }
56+
public string Name { get; set; }
57+
public string OtherName { get; set; }
58+
}
59+
----
60+
61+
By default NEST will try to find a property called `Routing` on the class using reflection
62+
and create a cached delegate based on the property getter
63+
64+
[source,csharp]
65+
----
66+
var dto = new MyDTO
67+
{
68+
Routing = new Guid("D70BD3CF-4E38-46F3-91CA-FCBEF29B148E"),
69+
Name = "x",
70+
OtherName = "y"
71+
};
72+
Expect(null).WhenInferringRoutingOn(dto);
73+
----
74+
75+
Using connection settings, you can specify a property that NEST should use to infer Routing for the document.
76+
Here we instruct NEST to infer the Routing for `MyDTO` based on its `Name` property
77+
78+
[source,csharp]
79+
----
80+
WithConnectionSettings(x => x
81+
.InferMappingFor<MyDTO>(m => m
82+
.RoutingProperty(p => p.Name)
83+
)
84+
).Expect("x").WhenInferringRoutingOn(dto);
85+
----
86+
87+
IMPORTANT: Inference rules are cached __per__ `ConnectionSettings` instance.
88+
89+
Because the cache is per `ConnectionSettings` instance, we can create another `ConnectionSettings` instance
90+
with different inference rules
91+
92+
[source,csharp]
93+
----
94+
WithConnectionSettings(x => x
95+
.InferMappingFor<MyDTO>(m => m
96+
.RoutingProperty(p => p.OtherName)
97+
)
98+
).Expect("y").WhenInferringRoutingOn(dto);
99+
----
100+
101+
==== JoinField
102+
103+
If your class has a property of type JoinField, NEST will automatically infer the parentid as the routing value.
104+
105+
The name of this property can be anything. Be sure the read the <<parent-child-relationships, section on Parent/Child relationships>> to get a complete
106+
walkthrough on using Parent Child joins with NEST.
107+
108+
[source,csharp]
109+
----
110+
class MyOtherDTO
111+
{
112+
public JoinField SomeJoinField { get; set; }
113+
public Guid Id { get; set; }
114+
public string Name { get; set; }
115+
public string OtherName { get; set; }
116+
}
117+
----
118+
119+
here we link this instance of `MyOtherDTO` with its parent id `"8080"`
120+
121+
[source,csharp]
122+
----
123+
var dto = new MyOtherDTO
124+
{
125+
SomeJoinField = JoinField.Link<MyOtherDTO>("8080"),
126+
Id = new Guid("D70BD3CF-4E38-46F3-91CA-FCBEF29B148E"),
127+
Name = "x",
128+
OtherName = "y"
129+
};
130+
Expect("8080").WhenInferringRoutingOn(dto);
131+
----
132+
133+
Here we link this instance as the root (parent) of the relation. NEST infers that the default routing for this instance
134+
should be the Id of the document itself.
135+
136+
[source,csharp]
137+
----
138+
dto = new MyOtherDTO
139+
{
140+
SomeJoinField = JoinField.Root<MyOtherDTO>(),
141+
Id = new Guid("D70BD3CF-4E38-46F3-91CA-FCBEF29B148E"),
142+
Name = "x",
143+
OtherName = "y"
144+
};
145+
Expect("d70bd3cf-4e38-46f3-91ca-fcbef29b148e").WhenInferringRoutingOn(dto);
146+
----
147+
148+
==== Precedence of ConnectionSettings
149+
150+
The routing property configured on `ConnectionSettings` always takes precedence.
151+
152+
[source,csharp]
153+
----
154+
WithConnectionSettings(x => x
155+
.InferMappingFor<MyOtherDTO>(m => m
156+
.RoutingProperty(p => p.OtherName)
157+
)
158+
).Expect("y").WhenInferringRoutingOn(dto);
159+
160+
class BadDTO
161+
{
162+
public JoinField SomeJoinField { get; set; }
163+
public JoinField AnotherJoinField { get; set; }
164+
public string ParentName { get; set; }
165+
}
166+
----
167+
168+
A class cannot contain more than one property of type JoinField, an exception is thrown in this case
169+
170+
[source,csharp]
171+
----
172+
var dto = new BadDTO
173+
{
174+
SomeJoinField = JoinField.Link<MyOtherDTO>("8080"),
175+
AnotherJoinField = JoinField.Link<MyOtherDTO>("8081"),
176+
ParentName = "my-parent"
177+
};
178+
Action resolve = () => Expect("8080").WhenInferringRoutingOn(dto);
179+
resolve.ShouldThrow<ArgumentException>().WithMessage("BadDTO has more than one JoinField property");
180+
----
181+
182+
unless you configure the ConnectionSettings to use an alternate property:
183+
184+
[source,csharp]
185+
----
186+
WithConnectionSettings(x => x
187+
.InferMappingFor<BadDTO>(m => m
188+
.RoutingProperty(p => p.ParentName)
189+
)
190+
).Expect("my-parent").WhenInferringRoutingOn(dto);
191+
----
192+

0 commit comments

Comments
 (0)