GEODE-7282: Geode Native Client .NET guide: Fix capitalization issues (#863)
diff --git a/docs/geode-native-docs-dotnet/continuous-queries.html.md.erb b/docs/geode-native-docs-dotnet/continuous-queries.html.md.erb
index 7cafbba..45e7827 100644
--- a/docs/geode-native-docs-dotnet/continuous-queries.html.md.erb
+++ b/docs/geode-native-docs-dotnet/continuous-queries.html.md.erb
@@ -51,12 +51,12 @@
## <a id="cq_api"></a>Typical Continuous Query Lifecycle
1. The client creates the CQ. This sets up everything for running the query and provides the client with a `CqQuery` object, but does not execute the CQ. At this point, the query is in a `STOPPED `state, ready to be closed or run.
-2. The client initiates the CQ with an API call to one of the `CqQuery execute*` methods. This puts the query into a `RUNNING` state on the client and on the server. The server remotely evaluates the query string, and optionally returns the results to the client. `CqQuery execute*` methods include:
+2. The client initiates the CQ with an API call to one of the `CqQuery Execute*` methods. This puts the query into a `RUNNING` state on the client and on the server. The server remotely evaluates the query string, and optionally returns the results to the client. `CqQuery Execute*` methods include:
- `CqQuery.Execute()`
- `CqQuery.ExecuteWithInitialResults()`
1. A CQ Listener waits for events. When it receives events, it takes action accordingly with the data in the CqEvent.
-3. The CQ is closed by a client call to `CqQuery.close`. This de-allocates all resources in use for the CQ on the client and server. At this point, the cycle could begin again with the creation of a new `CqQuery` instance.
+3. The CQ is closed by a client call to `CqQuery.Close`. This de-allocates all resources in use for the CQ on the client and server. At this point, the cycle could begin again with the creation of a new `CqQuery` instance.
## <a id="ExecutingACQ"></a>Executing a Continuous Query from the Client
@@ -64,7 +64,7 @@
1. Create an instance of the `QueryService` class. If you are using the pool API (recommended), you should obtain the `QueryService` from the pool.
1. Define a CQ Listener (an `ICqListener`) to field events sent from the server.
-1. Use one of the `CqQuery execute*` methods to submit the query string to the cache server.
+1. Use one of the `CqQuery Execute*` methods to submit the query string to the cache server.
1. The server remotely evaluates the query string, then monitors those results and notifies the client if they change.
1. The client listens for changes that match the query predicate.
1. Iterate through the returned objects.
diff --git a/docs/geode-native-docs-dotnet/function-execution.html.md.erb b/docs/geode-native-docs-dotnet/function-execution.html.md.erb
index 0f10d55..126530b 100644
--- a/docs/geode-native-docs-dotnet/function-execution.html.md.erb
+++ b/docs/geode-native-docs-dotnet/function-execution.html.md.erb
@@ -37,43 +37,43 @@
## <a id="nc-fe-how_functions_execute"></a>How Functions Execute
-1. The calling client application runs the `execute` method on the `Execution` object. The function must already be registered on the servers.
-2. The function is invoked on the servers where it needs to run. The servers are determined by the `FunctionService on*`
+1. The calling client application runs the `Execute` method on the `Execution` object. The function must already be registered on the servers.
+2. The function is invoked on the servers where it needs to run. The servers are determined by the `FunctionService On*`
method calls, region configuration, and any filters.
3. If the function has results, the result is returned in a `ResultCollector` object.
-4. The client collects results using the `ResultCollector.getResult()` method.
+4. The client collects results using the `ResultCollector.GetResult()` method.
In every client where you want to execute the function and process the results:
-- Use one of the `FunctionService on*` methods to create an `Execution` object. The `on*` methods,
-`onRegion`, `onServer` and `onServers`, define the highest level where the function is run.
-- If you use `onRegion` you can further narrow your run scope by setting key filters.
-- A function run using `onRegion` is a *data dependent* function – others are *data-independent* functions.
+- Use one of the `FunctionService On*` methods to create an `Execution` object. The `On*` methods,
+`OnRegion`, `OnServer` and `OnServers`, define the highest level where the function is run.
+- If you use `OnRegion` you can further narrow your run scope by setting key filters.
+- A function run using `OnRegion` is a *data dependent* function – others are *data-independent* functions.
- You can run a data dependent function against partitioned and colocated partitioned regions. From the client, provide the appropriate key
sets to the function call.
- The `Execution` object allows you to customize the invocation by:
- - Providing a set of data keys to `withFilter` to narrow the execution scope. This works only for `onRegion` Execution objects (data-dependent functions).
- - Providing function arguments to `withArgs`.
- - Defining a custom `ResultCollector` for `withCollector`.
+ - Providing a set of data keys to `WithFilter` to narrow the execution scope. This works only for `OnRegion` Execution objects (data-dependent functions).
+ - Providing function arguments to `WithArgs`.
+ - Defining a custom `ResultCollector` for `WithCollector`.
-- Call the `Execution.execute()` method to run the function.
+- Call the `Execution.Execute()` method to run the function.
## <a id="nc-fe-processing_function_results"></a>Processing Function Results
To get the results from the function in the client app, use the result collector returned from the function execution.
-The `getResult` methods of the default result collector block until all results are received, then return the full result set.
+The `GetResult` methods of the default result collector block until all results are received, then return the full result set.
The client can use the default result collector. If the client needs special results handling, code a custom `ResultsCollector` implementation to replace the default.
Use the `Execution::withCollector` method to specify the custom collector.
To handle the results in a custom manner:
1. Write a class that implements the `ResultCollector` interface to handle the results in a custom manner. The methods are of two types: one handles data and information from <%=vars.product_name%> and populates the results set, while the other returns the compiled results to the calling application:
- - `addResult` is called when results arrive from the `Function` methods. Use `addResult` to add a single result to the ResultCollector.
- - `endResults` is called to signal the end of all results from the function execution.
- - `getResult` is available to your executing application (the one that calls `Execution.execute`) to retrieve the results. This may block until all results are available.
- - `clearResults` is called to clear partial results from the results collector. This is used only for highly available `onRegion` functions where the calling application waits for the results. If the call fails, before <%=vars.product_name%> retries the execution, it calls `clearResults` to ready the instance for a clean set of results.
-2. Use the `Execution` object in your executing member to call `withCollector`, passing your custom collector.
+ - `AddResult` is called when results arrive from the `Function` methods. Use `AddResult` to add a single result to the ResultCollector.
+ - `EndResults` is called to signal the end of all results from the function execution.
+ - `GetResult` is available to your executing application (the one that calls `Execution.Execute`) to retrieve the results. This may block until all results are available.
+ - `ClearResults` is called to clear partial results from the results collector. This is used only for highly available `OnRegion` functions where the calling application waits for the results. If the call fails, before <%=vars.product_name%> retries the execution, it calls `ClearResults` to ready the instance for a clean set of results.
+2. Use the `Execution` object in your executing member to call `WithCollector`, passing your custom collector.
## <a id="nc-fe-examples"></a>Function Execution Example
@@ -83,7 +83,7 @@
- The function is preloaded with a JAR file containing the server-side Java function code.
- The function, called "ExampleMultiGetFunction", is defined in the
`examples/utilities` directory of your distribution. As its input parameter, the function takes an array of keys,
-then performs a `get` on each key and returns an array containing the results.
+then performs a `Get` on each key and returns an array containing the results.
- The function does not load values into the data store. That is a separate operation, performed in these examples by
the client, and does not involve the server-side function.
@@ -97,7 +97,7 @@
- invokes the object's execute method to invoke the server-side function
If the client expects results, it must create a result object.
-The .NET example uses a built-in result collector (`IResultCollector.getResults()`) to retrieve the function results.
+The .NET example uses a built-in result collector (`IResultCollector.GetResults()`) to retrieve the function results.
### <a id="nc-fe-dotnet_example"></a>.NET Example
This section contains code snippets showing highlights of the .NET function execution example. They are not intended for cut-and-paste execution.
diff --git a/docs/geode-native-docs-dotnet/preserving-data/config-durable-interest-keys.html.md.erb b/docs/geode-native-docs-dotnet/preserving-data/config-durable-interest-keys.html.md.erb
index 04f8601..221ccc0 100644
--- a/docs/geode-native-docs-dotnet/preserving-data/config-durable-interest-keys.html.md.erb
+++ b/docs/geode-native-docs-dotnet/preserving-data/config-durable-interest-keys.html.md.erb
@@ -1,4 +1,4 @@
----
+--
title: Configuring Durable Interest in Keys
---
@@ -25,7 +25,7 @@
You still register interest for other keys, but not durable interest. When the client is connected to its servers, it receives messages for those non-durable keys. When the client is disconnected, its non-durable interest registrations are deleted but messages that are already in the queue remain there.
-For durable clients, all interest registration is done immediately after the regions are created. This is required whether interest registration is durable or not durable. An extra `registerInterest` parameter specified for durable clients indicates whether the registration is durable (true) or not (false).
+For durable clients, all interest registration is done immediately after the regions are created. This is required whether interest registration is durable or not durable. An extra `RegisterInterest` parameter specified for durable clients indicates whether the registration is durable (true) or not (false).
## API Client Durable Interest List Registration (C++)
@@ -36,7 +36,7 @@
// durable (true) or nondurable(default).
VectorOfCacheableKey keys;
keys.push_back( CacheableString::create("Key-1") );
-regionPtr->registerKeys(keys,true);
+regionPtr->RegisterKeys(keys,true);
```
<a id="concept_6456354A9AD945C780A5AA864B41B564__section_3DE5872B0888410EB42D52CFB28C79E5"></a>
diff --git a/docs/geode-native-docs-dotnet/regions/registering-interest-for-entries.html.md.erb b/docs/geode-native-docs-dotnet/regions/registering-interest-for-entries.html.md.erb
index a7cb1b0..d410874 100644
--- a/docs/geode-native-docs-dotnet/regions/registering-interest-for-entries.html.md.erb
+++ b/docs/geode-native-docs-dotnet/regions/registering-interest-for-entries.html.md.erb
@@ -23,18 +23,18 @@
You can register interest for specific entry keys or for all keys. Regular expressions can be used to register interest for keys whose strings match the expression. You can also unregister interest for specific keys, groups of keys based on regular expressions, or for all keys.
-**Note:** Interest registration and unregistration are symmetrical operations. Consequently, you cannot register interest in all keys and then unregister interest in a specific set of keys. Also, if you first register interest in specific keys with `registerKeys`, then call `registerAllKeys`, you must call `unregisterAllKeys` before specifying interest in specific keys again.
+**Note:** Interest registration and unregistration are symmetrical operations. Consequently, you cannot register interest in all keys and then unregister interest in a specific set of keys. Also, if you first register interest in specific keys with `RegisterKeys`, then call `RegisterAllKeys`, you must call `UnregisterAllKeys` before specifying interest in specific keys again.
## <a id="registering-interest-for-entries__section_C9A3D7F193B24ACD83B2D67813E596A0" class="no-quick-link"></a>Client API for Registering Interest
You register client interest through the .NET API. The .NET API provides the `RegisterKeys`, `RegisterAllKeys`, and `RegisterRegex` methods, with corresponding unregistration accomplished using the `UnregisterKeys`, `UnregisterAllKeys`, and `UnregisterRegex` methods.
-The `registerKeys`, `registerRegex` and `registerAllKeys` methods have the option to populate the cache with the registration results from the server. The `registerRegex` and `registerAllKeys` methods can also optionally return the current list of keys registered on the server.
+The `RegisterKeys`, `RegisterRegex` and `RegisterAllKeys` methods have the option to populate the cache with the registration results from the server. The `RegisterRegex` and `RegisterAllKeys` methods can also optionally return the current list of keys registered on the server.
## <a id="registering-interest-for-entries__section_C1A3F89EE73448D7AFF2076F41848F55" class="no-quick-link"></a>Setting Up Client Notification
-In addition to the programmatic function calls, to register interest for a server region and receive updated entries you need to configure the region with the `PROXY` or `CACHING_PROXY RegionShortcut` setting. The region's pool should have `subscription-enabled=true` set either in the client XML or programmatically via a `CacheFactory::setSubscriptionEnabled(true)` API call. Otherwise, when you register interest, you will get an `UnsupportedOperationException`.
+In addition to the programmatic function calls, to register interest for a server region and receive updated entries you need to configure the region with the `PROXY` or `CACHING_PROXY RegionShortcut` setting. The region's pool should have `subscription-enabled=true` set either in the client XML or programmatically via a `CacheFactory::SetSubscriptionEnabled(true)` API call. Otherwise, when you register interest, you will get an `UnsupportedOperationException`.
``` pre
<region name="listenerWriterLoader" refid="CACHING_PROXY">
@@ -45,26 +45,26 @@
**Notification Sequence**
-Notifications invoke `CacheListeners` of cacheless clients in all cases for keys that have been registered on the server. Similarly, invalidates received from the server invoke `CacheListeners` of cacheless clients.
+Notifications invoke `CacheListeners` of cacheless clients in all cases for keys that have been registered on the server. Similarly, Invalidate events received from the server invoke `CacheListeners` of cacheless clients.
-If you register to receive notifications, listener callbacks are invoked irrespective of whether the key is in the client cache when a `destroy` or `invalidate` event is received.
+If you register to receive notifications, listener callbacks are invoked irrespective of whether the key is in the client cache when a `Destroy` or `Invalidate` event is received.
## <a id="registering-interest-for-entries__section_8772147940754C2D9688C789EB2F2AA6" class="no-quick-link"></a>Registering Interest for Specific Keys
-You register and unregister interest for specific keys through the `registerKeys` and `unregisterKeys` functions. You register interest in a key or set of keys by specifying the key name using the programmatic syntax shown in the following example:
+You register and unregister interest for specific keys through the `RegisterKeys` and `UnregisterKeys` functions. You register interest in a key or set of keys by specifying the key name using the programmatic syntax shown in the following example:
``` pre
keys0.push_back(keyPtr1);
keys1.push_back(keyPtr3);
-regPtr0->registerKeys(keys0);
-regPtr1->registerKeys(keys1);
+regPtr0->RegisterKeys(keys0);
+regPtr1->RegisterKeys(keys1);
```
The programmatic code snippet in the next example shows how to unregister interest in specific keys:
``` pre
-regPtr0->unregisterKeys(keys0);
-regPtr1->unregisterKeys(keys1);
+regPtr0->UnregisterKeys(keys0);
+regPtr1->UnregisterKeys(keys1);
```
## <a id="registering-interest-for-entries__section_EA4525CCDC474DD495410E948EAF566C" class="no-quick-link"></a>Registering Interest for All Keys
@@ -72,33 +72,33 @@
If the client registers interest in all keys, the server provides notifications for all updates to all keys in the region. The next example shows how to register interest in all keys:
``` pre
-regPtr0->registerAllKeys();
-regPtr1->registerAllKeys();
+regPtr0->RegisterAllKeys();
+regPtr1->RegisterAllKeys();
```
The following example shows a code sample for unregistering interest in all keys.
``` pre
-regPtr0->unregisterAllKeys();
-regPtr1->unregisterAllKeys();
+regPtr0->UnregisterAllKeys();
+regPtr1->UnregisterAllKeys();
```
## <a id="registering-interest-for-entries__section_BD50B80FCE9F429C8F6A9FEA818D5A91" class="no-quick-link"></a>Registering Interest Using Regular Expressions
-The `registerRegex` function registers interest in a regular expression pattern. The server automatically sends the client changes for entries whose keys match the specified pattern.
+The `RegisterRegex` function registers interest in a regular expression pattern. The server automatically sends the client changes for entries whose keys match the specified pattern.
*Keys must be strings in order to register interest using regular expressions.*
The following example shows interest registration for all keys whose first four characters are `Key-`, followed by any string of characters. The characters `.*` represent a wildcard that matches any string.
``` pre
-regPtr1->registerRegex("Key-.*");
+regPtr1->RegisterRegex("Key-.*");
```
-To unregister interest using regular expressions, you use the `unregisterRegex` function. The next example shows how to unregister interest in all keys whose first four characters are `Key-`, followed by any string (represented by the `.*` wildcard).
+To unregister interest using regular expressions, you use the `UnregisterRegex` function. The next example shows how to unregister interest in all keys whose first four characters are `Key-`, followed by any string (represented by the `.*` wildcard).
``` pre
-regPtr1->unregisterRegex("Key-.*");
+regPtr1->UnregisterRegex("Key-.*");
```
## <a id="registering-interest-for-entries__section_2D71A423B185493489129AAC30DC6733" class="no-quick-link"></a>Register Interest Scenario
diff --git a/docs/geode-native-docs-dotnet/remote-queries.html.md.erb b/docs/geode-native-docs-dotnet/remote-queries.html.md.erb
index a93901f..15e4f6b 100644
--- a/docs/geode-native-docs-dotnet/remote-queries.html.md.erb
+++ b/docs/geode-native-docs-dotnet/remote-queries.html.md.erb
@@ -72,7 +72,7 @@
1. Create an instance of the `QueryService` class. If you are using the pool API (recommended), you should obtain the `QueryService` from the pool.
1. Create a `Query` instance that is compatible with the OQL specification.
-1. Use the `Query.execute()` method to submit the query string to the cache server. The server
+1. Use the `Query.Execute()` method to submit the query string to the cache server. The server
remotely evaluates the query string and returns the results to the client.
1. Iterate through the returned objects.
diff --git a/docs/geode-native-docs-dotnet/serialization/dotnet-serialization/dotnet-pdx-autoserializer.html.md.erb b/docs/geode-native-docs-dotnet/serialization/dotnet-serialization/dotnet-pdx-autoserializer.html.md.erb
index 3019187..b86d5c1 100644
--- a/docs/geode-native-docs-dotnet/serialization/dotnet-serialization/dotnet-pdx-autoserializer.html.md.erb
+++ b/docs/geode-native-docs-dotnet/serialization/dotnet-serialization/dotnet-pdx-autoserializer.html.md.erb
@@ -68,5 +68,3 @@
```
For each domain class <%=vars.product_name%> serializes using the autoserializer, all fields are considered for serialization except those defined as `static`, `literal` or `readonly` and those you explicitly exclude using the .NET `NonSerialized` attribute.
-
-
diff --git a/docs/geode-native-docs-dotnet/serialization/dotnet-serialization/serialize-using-ipdxserializable.html.md.erb b/docs/geode-native-docs-dotnet/serialization/dotnet-serialization/serialize-using-ipdxserializable.html.md.erb
index cddda23..b4f1b69 100644
--- a/docs/geode-native-docs-dotnet/serialization/dotnet-serialization/serialize-using-ipdxserializable.html.md.erb
+++ b/docs/geode-native-docs-dotnet/serialization/dotnet-serialization/serialize-using-ipdxserializable.html.md.erb
@@ -37,7 +37,7 @@
3. Program the `IPdxSerializable ToData` function to serialize your object as required by your application.
1. Write your domain class's standard .NET data fields using the `IPdxWriter` write methods. <%=vars.product_name%> automatically provides `IPdxWriter` to the `ToData` function for `IPdxSerializable` objects.
- 2. Call the `ToData markIdentifyField` function for each field <%=vars.product_name%> should use to identify your object. This is used to compare objects for operations like `DISTINCT` queries. The `markIdentifyField` call must come after the associated field write methods.
+ 2. Call the `ToData MarkIdentifyField` function for each field <%=vars.product_name%> should use to identify your object. This is used to compare objects for operations like `DISTINCT` queries. The `MarkIdentifyField` call must come after the associated field write methods.
Example:
@@ -115,6 +115,6 @@
}
```
-5. Optionally, program your domain object's equals and hashcode methods.
+5. Optionally, program your domain object's `Equals` and `Hashcode` methods.
diff --git a/docs/geode-native-docs-dotnet/transactions.html.md.erb b/docs/geode-native-docs-dotnet/transactions.html.md.erb
index 367d70e..25aea84 100644
--- a/docs/geode-native-docs-dotnet/transactions.html.md.erb
+++ b/docs/geode-native-docs-dotnet/transactions.html.md.erb
@@ -26,8 +26,8 @@
## <a id="client-transaction-apis"></a>Native Client Transaction APIs
-The API for distributed transactions has the familiar relational database methods, `begin`,
-`commit`, and `rollback`. There are also APIs available to suspend and resume transactions.
+The API for distributed transactions has the familiar relational database methods, `Begin`,
+`Commit`, and `Rollback`. There are also APIs available to suspend and resume transactions.
The .NET classes for executing transactions are:
@@ -40,7 +40,7 @@
a client performs a transaction, the transaction is delegated to a server that brokers the
transaction.
-Start each transaction with a `begin` operation, and end the transaction with a `commit` or a `rollback`.
+Start each transaction with a `Begin` operation, and end the transaction with a `Commit` or a `Rollback`.
To maintain cache consistency, the local client cache is not used during a transaction.
When the transaction completes or is suspended, local cache usage is reinstated.
@@ -112,7 +112,7 @@
```csharp
foreach(var key in keys)
{
- var value = getValueFromExternalSystem();
+ var value = GetValueFromExternalSystem();
region.Put(key, value);
}
```
