docs/_docs/developers-guide/clients/cpp.adoc

// Licensed to the Apache Software Foundation (ASF) under one or more
// contributor license agreements.  See the NOTICE file distributed with
// this work for additional information regarding copyright ownership.
// The ASF licenses this file to You under the Apache License, Version 2.0
// (the "License"); you may not use this file except in compliance with
// the License.  You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
= C++ Client

Ignite 3 clients connect to the cluster via a standard socket connection. Unlike Ignite 2.x, there are no separate Thin and Thick clients in Ignite 3. All clients are 'thin'.

Clients do not become a part of the cluster topology, never hold any data, and are not used as a destination for compute calculations.

== Getting Started
=== Prerequisites

To run C\++ client, you need a C++ build environment to run the `cmake` command:

- C\++ compiler supporting C++ 17;
- CMake 3.10+;
- One of build systems: make, ninja, MS Visual Studio, or other;
- Conan C/C++ package manager 1.X (optional).


=== [[build-ref]]Installation

The source code of the C++ client comes with the Ignite 3 distribution. To build it, use the following commands:


[tabs]
--
tab:Windows[]
[source,bat]
----
mkdir cmake-build-release
cd cmake-build-release
conan install .. --build=missing -s build_type=Release
cmake ..
cmake --build . -j8
----

tab:Linux[]
[source,bash,subs="attributes,specialchars"]
----
mkdir cmake-build-release
cd cmake-build-release
conan install .. --build=missing -s build_type=Release -s compiler.libcxx=libstdc++11
cmake .. -DCMAKE_BUILD_TYPE=Release
cmake --build . -j8
----

tab:MacOS[]
[source,bash,subs="attributes,specialchars"]
----
mkdir cmake-build-release
cd cmake-build-release
conan install .. --build=missing -s build_type=Release -s compiler.libcxx=libc++
cmake .. -DCMAKE_BUILD_TYPE=Release
cmake --build . -j8
----

--

=== Building C++ Client on CentOS 7 and RHEL 7

If you are running on older systems, you need to set up the environment in the following way:

. Install `epel-release` and `centos-release-scl`:
+
[source,bash]
----
yum install epel-release centos-release-scl
----
+
. Update yum and accept `epel-release` keys:
+
[source,bash]
----
yum update
----
+
. Install the build tools from the main repository and `devtoolset-11`:
+
[source,bash]
----
yum install devtoolset-11-gcc devtoolset-11-gcc-c++ cmake3 git java-11-openjdk-devel gtest-devel gmock-devel
----
+
. Install `conan` version 1.56.0 or more recent but older than 2.00:
+
[source,bash]
----
pip3 install -v "conan>=1.56.0,<2.0.0" --force-reinstall
----
+
. Create and update alternatives for `cmake` to force the use of `cmake3`:
.. Create an alternative for `cmake2` with priority 10:
+
[source,bash]
----
sudo alternatives --install /usr/local/bin/cmake cmake /usr/bin/cmake 10 \
--slave /usr/local/bin/ctest ctest /usr/bin/ctest \
--slave /usr/local/bin/cpack cpack /usr/bin/cpack \
--slave /usr/local/bin/ccmake ccmake /usr/bin/ccmake \
--family cmake
----
+
.. Create an alternative for `cmake3` with priority 20:
+
[source,bash]
----
sudo alternatives --install /usr/local/bin/cmake cmake /usr/bin/cmake3 20 \
--slave /usr/local/bin/ctest ctest /usr/bin/ctest3 \
--slave /usr/local/bin/cpack cpack /usr/bin/cpack3 \
--slave /usr/local/bin/ccmake ccmake /usr/bin/ccmake3 \
--family cmake
----
+
.. Check that the default alternative points to `cmake3`:
+
[source,bash]
----
sudo alternatives --config cmake
----
+
. Enable the `devtoolset-11` compiler and start bash with the updated PATH:
+
[source,bash]
----
scl enable devtoolset-11 bash
----
+
. Start the link:clients/overview#build-ref[build] in the shell you have established.

== Client Connector Configuration

Client connection parameters are controlled by the client connector configuration. By default, Ignite accepts client connections on port 10800. You can change the configuration for the node by using the link:ignite-cli-tool[CLI tool] at any time.

Here is how the client connector configuration looks like:

[source, json]
----
"clientConnector": {
  "port": 10800,
  "idleTimeout":3000,
  "sendServerExceptionStackTraceToClient":true,
  "ssl": {
    enabled: true,
    clientAuth: "require",
    keyStore: {
      path: "KEYSTORE_PATH",
      password: "SSL_STORE_PASS"
    },
    trustStore: {
      path: "TRUSTSTORE_PATH",
      password: "SSL_STORE_PASS"
    }
  }
}

----

//NOTE: Replace with link to javadoc once it is published.

The table below covers the configuration for client connector:

[cols="1,1,3",opts="header", stripes=none]
|======
|Property|Default|Description

|connectTimeout|5000| Connection attempt timeout, in milliseconds.
|idleTimeout|0|How long the client can be idle before the connection is dropped,in milliseconds. By default, there is no limit.
|metricsEnabled|`false`|Defines if client metrics are collected.
|port|10800|The port the client connector will be listening to.
|sendServerExceptionStackTraceToClient|`false`|Defines if cluster exceptions are sent to the client.
|ssl.ciphers||The cipher used for SSL communication.
|ssl.clientAuth||Type of client authentication used by clients. For more information, see link:security/ssl-tls[SSL/TLS].
|ssl.enabled||Defines if SSL is enabled.
|ssl.keyStore.password||SSL keystore password.
|ssl.keyStore.path||Path to the SSL keystore.
|ssl.keyStore.type|`PKCS12`|The type of SSL keystore used.
|ssl.trustStore.password||SSL keystore password.
|ssl.trustStore.path||Path to the SSL keystore.
|ssl.trustStore.type|`PKCS12`|The type of SSL keystore used.
|======

Here is how you can change the parameters:


----
node config update clientConnector.port=10469
----


== Connecting to Cluster

To initialize a client, use the `IgniteClient` class, and provide it with the configuration:

[tabs]
--
tab:C++[]
[source, cpp]
----
using namespace ignite;

ignite_client_configuration cfg{"127.0.0.1"};
auto client = ignite_client::start(cfg, std::chrono::seconds(5));
----
--

== Authentication

To pass authentication information, pass it to `IgniteClient` builder:

[tabs]
--
tab:Java[]
[source, java]
----
auto authenticator = std::make_shared<ignite::basic_authenticator>("myUser", "myPassword");

ignite::ignite_client_configuration cfg{"127.0.0.1:10800"};
cfg.set_authenticator(authenticator);
auto client = ignite_client::start(std::move(cfg), std::chrono::seconds(30));
----
--

== User Object Serialization

Ignite supports mapping user objects to table tuples. This ensures that objects created in any programming language can be used for key-value operations directly.

=== Limitations

There are limitations to user types that can be used for such a mapping. Some limitations are common, and others are platform-specific due to the programming language used.

- Only flat field structure is supported, meaning no nesting user objects. This is because Ignite tables, and therefore tuples have flat structure themselves;
- Fields should be mapped to Ignite types;
- All fields in user type should either be mapped to Table column or explicitly excluded;
- All columns from Table should be mapped to some field in the user type;
- *C++ only*: User has to provide marshaling functions explicitly as there is no reflection to generate them based on user type structure.

=== Usage Examples


[tabs]
--
tab:C++[]
[source, cpp]
----
struct account {
  account() = default;
  account(std::int64_t id) : id(id) {}
  account(std::int64_t id, std::int64_t balance) : id(id), balance(balance) {}

  std::int64_t id{0};
  std::int64_t balance{0};
};

namespace ignite {

  template<>
  ignite_tuple convert_to_tuple(account &&value) {
    ignite_tuple tuple;

    tuple.set("id", value.id);
    tuple.set("balance", value.balance);

    return tuple;
  }

  template<>
  account convert_from_tuple(ignite_tuple&& value) {
    account res;

    res.id = value.get<std::int64_t>("id");

    // Sometimes only key columns are returned, i.e. "id",
    // so we have to check whether there are any other columns.
    if (value.column_count() > 1)
      res.balance = value.get<std::int64_t>("balance");

    return res;
  }

} // namespace ignite
----
--


== SQL API

Ignite 3 is focused on SQL, and SQL API is the primary way to work with the data. You can read more about supported SQL statements in the link:sql-reference/ddl[SQL Reference] section. Here is how you can send SQL requests:

[tabs]
--
tab:C++[]
[source, cpp]
----
result_set result = client.get_sql().execute(nullptr, {"select name from tbl where id = ?"}, {std::int64_t{42});
std::vector<ignite_tuple> page = result_set.current_page();
ignite_tuple& row = page.front();
----

--


=== SQL Scripts

The default API executes SQL statements one at a time. If you want to execute large SQL statements, pass them to the `executeScript()` method. These statements will be executed in order.

[tabs]
--
tab:C++[]
[source, cpp]
----
std::string script = ""
	+ "CREATE TABLE IF NOT EXISTS Person (id int primary key, city_id int, name varchar, age int, company varchar);"
	+ "INSERT INTO Person (1,3, 'John', 43, 'Sample')";

client.get_sql().execute_script(script);
----
--

NOTE: Execution of each statement is considered complete when the first page is ready to be returned. As a result, when working with large data sets, SELECT statement may be affected by later statements in the same script.

== Transactions

All table operations in Ignite 3 are transactional. You can provide an explicit transaction as a first argument of any Table and SQL API call. If you do not provide an explicit transaction, an implicit one will be created for every call.

Here is how you  can provide a transaction explicitly:

[tabs]
--
tab:C++[]
[source, cpp]
----
auto accounts = table.get_key_value_view<account, account>();

account init_value(42, 16'000);
accounts.put(nullptr, {42}, init_value);

auto tx = client.get_transactions().begin();

std::optional<account> res_account = accounts.get(&tx, {42});
res_account->balance += 500;
accounts.put(&tx, {42}, res_account);

assert(accounts.get(&tx, {42})->balance == 16'500);

tx.rollback();

assert(accounts.get(&tx, {42})->balance == 16'000);
----

--

== Table API

To execute table operations on a specific table, you need to get a specific view of the table and use one of its methods. You can only create new tables by using SQL API.

When working with tables, you can use built-in Tuple type, which is a set of key-value pairs underneath, or map the data to your own types for a strongly-typed access. Here is how you can work with tables:

=== Getting a Table Instance

First, get an instance of the table. To obtain an instance of table, use the `IgniteTables.table(String)` method. You can also use `IgniteTables.tables()` method to list all existing tables.


[tabs]
--
tab:C++[]
[source, cpp]
----
using namespace ignite;

auto table_api = client.get_tables();
std::vector<table> existing_tables = table_api.get_tables();
table first_table = existing_tables.front();

std::optional<table> my_table = table_api.get_table("MY_TABLE);
----
--

=== Basic Table Operations

Once you've got a table you need to get a specific view to choose how you want to operate table records.

==== Binary Record View

A binary record view. It can be used to operate table tuples directly.

[tabs]
--
tab:C++[]
[source, cpp]
----
record_view<ignite_tuple> view = table.get_record_binary_view();

ignite_tuple record{
  {"id", 42},
  {"name", "John Doe"}
};

view.upsert(nullptr, record);
std::optional<ignite_tuple> res_record = view.get(nullptr, {"id", 42});

assert(res_record.has_value());
assert(res_record->column_count() == 2);
assert(res_record->get<std::int64_t>("id") == 42);
assert(res_record->get<std::string>("name") == "John Doe");
----

--

==== Record View

A record view mapped to a user type. It can be used to operate table using user objects which are mapped to table tuples.

[tabs]
--
tab:C++[]
[source, cpp]
----
record_view<person> view = table.get_record_view<person>();

person record(42, "John Doe");

view.upsert(nullptr, record);
std::optional<person> res_record = view.get(nullptr, person{42});

assert(res.has_value());
assert(res->id == 42);
assert(res->name == "John Doe");
----

--

==== Key-Value Binary View

A binary key-value view. It can be used to operate table using key and value tuples separately.

[tabs]
--
tab:C++[]
[source, cpp]
----
key_value_view<ignite_tuple, ignite_tuple> kv_view = table.get_key_value_binary_view();

ignite_tuple key_tuple{{"id", 42}};
ignite_tuple val_tuple{{"name", "John Doe"}};

kv_view.put(nullptr, key_tuple, val_tuple);
std::optional<ignite_tuple> res_tuple = kv_view.get(nullptr, key_tuple);

assert(res_tuple.has_value());
assert(res_tuple->column_count() == 2);
assert(res_tuple->get<std::int64_t>("id") == 42);
assert(res_tuple->get<std::string>("name") == "John Doe");
----
--


==== Key-Value View

A key-value view with user objects. It can be used to operate table using key and value user objects mapped to table tuples.

[tabs]
--
tab:C++[]
[source, cpp]
----
key_value_view<person, person> kv_view = table.get_key_value_view<person, person>();

kv_view.put(nullptr, {42}, {"John Doe"});
std::optional<person> res = kv_view.get(nullptr, {42});

assert(res.has_value());
assert(res->id == 42);
assert(res->name == "John Doe");
----
--

== Streaming Data

To stream a large amount of data, use the data streamer. Data streaming provides a quicker and more efficient way to load, organize and optimally distribute your data. Data streamer accepts a stream of data and distributes data entries across the cluster, where the processing takes place. Data streaming is available in all table views.

image::images/data_streaming.png[]

Data streaming provides at-least-once delivery guarantee.

=== Using Data Streamer API

[tabs]
--
tab:.NET[]
[source, csharp]
----
public async Task TestBasicStreamingRecordBinaryView()
{
    var options = DataStreamerOptions.Default with { BatchSize = 10 };
    var data = Enumerable.Range(0, Count).Select(x => new IgniteTuple { ["id"] = 1L, ["name"] = "foo" }).ToList();

    await TupleView.StreamDataAsync(data.ToAsyncEnumerable(), options);
}
----
--