anchor.diff:    age int,
     company varchar,
     PRIMARY KEY (id, city_id)
  -) WITH "template=partitioned,backups=1,affinity_key=city_id, key_type=PersonKey, value_type=MyPerson";
  -----
  -
  -Once the CREATE TABLE command gets executed, the following happens:
  -
  -- A new distributed cache is created and named SQL_PUBLIC_PERSON. This cache stores objects of the `Person` type that corresponds to a specific Java, .NET, C++ class or BinaryObject. Furthermore, the key type (`PersonKey`) and value type (`MyPerson`) are defined explicitly assuming the data is to be processed by key-value and other non-SQL APIs.
  -- SQL table/schema with all the parameters will be defined.
  -- The data will be stored in the form of key-value pairs. The `PRIMARY KEY` columns will be used as the object's key; the rest of the columns will belong to the value.
  -- Distributed cache related parameters are passed in the `WITH` clause of the statement. If the `WITH` clause is omitted, then the cache will be created with default parameters set in the CacheConfiguration object.
  -
  -The example below shows how to create the same table with `PRIMARY KEY` specified in the column definition and overrid some cache related parameters:
  -
  -[source,sql]
  -----
  -CREATE TABLE Person (
  -  id int PRIMARY KEY,
  -  city_id int,
  -  name varchar,
  -  age int,
  -  company varchar
  -) WITH "atomicity=transactional,cachegroup=somegroup";
  -----
  +) WITH "template=partitioned,backups=1,affinity_key=city_id,CACHE_NAME=Person,KEY_TYPE=PersonKey,VALUE_TYPE=PersonValue";
  +----
  +
  +
  +=== Use non-Upper Case Columns
  +
  +Ignite parses all unquoted identifiers, names of a table columns and converts them to uppercase
  +during the `CREATE TABLE` command execution which, in turn, makes the command with explicitly defined key
  +and value types a bit more challenging.
  +
  +There are a few options that might help you to deal with such a case:
  +
  +* Use link:SQL/sql-api[QuerySqlField] annotation. This will prevent checking the field non-UpperCase each time because of
  +an alias for the column is created each time the `CREATE TABLE` command being executed.
  +* Keeping in mind that column names converted each time to the upper case by default, you have to be sure that DDL fields
  +and cache type fields are always match the letters case.
  +
  +In the example below you can see the usage of quotes for the `affKey` CamelCase field in the `CREATE TABLE` command with
  +matching of the same field in the `PersonKey` cache key type.
  +
  +[source,sql]
  +----
  +CREATE TABLE IF NOT EXISTS Person (
  +  id INT,
  +  "affKey" INT,
  +  val VARCHAR,
  +  PRIMARY KEY (id, "affKey")
  +) WITH "template=partitioned,backups=1,affinity_key=affKey,CACHE_NAME=Person,KEY_TYPE=PersonKey,VALUE_TYPE=PersonValue";
  +----
  +
  +[source,java]
  +----
  +class PersonKey {
  +    private int id;
  +
  +    /*
  +     * This is a camel case field 'affKey' must match the DDL table schema, so you must be sure:
  +     * - Using the quoted "affKey" field name in the DDL table definition;
  +     * - Convert the 'affKey' field to the upper case 'AFFKEY' to match the DDL table definition;
  +     */
  +    @AffinityKeyMapped
  +    private int affKey;
  +
  +    public PersonKey(int id, int affKey) {
  +        this.id = id;
  +        this.affKey = affKey;
  +    }
  +}
  +----
  +
  +Note that some integrations with the Apache Ignite like the link:extensions-and-integrations/spring/spring-data[Spring Data]
  +`CrudRepository` doesn't support the quoted fields to access the data.
   
   
   == ALTER TABLE
  
positive.code: ** `WRAP_KEY=<true | false>` - this flag controls whether a _single column_ `PRIMARY KEY` should be wrapped in the link:data-modeling/data-modeling#binary-object-format[BinaryObjects] format or not. By default, this flag is set to false. This flag does not have any effect on the `PRIMARY KEY` with multiple columns; it always gets wrapped regardless of the value of the parameter.
  ** `WRAP_VALUE=<true | false>` - this flag controls whether a single column value of a primitive type should be wrapped in the link:data-modeling/data-modeling#binary-object-format[BinaryObjects] format or not. By default, this flag is set to true. This flag does not have any effect on the value with multiple columns; it always gets wrapped regardless of the value of the parameter. Set this parameter to false if you have a single column value and do not plan to add additional columns to the table. Note that once the parameter is set to false, you can't use the `ALTER TABLE ADD COLUMN` command for this specific table.
  
  The CREATE TABLE command creates a new Ignite cache and defines a SQL table on top of it. The cache stores the data in the form of key-value pairs while the table allows processing the data with SQL queries.
  
  The table will reside in the schema specified in the connection parameters. If no schema is specified, the PUBLIC schema will be used. See link:SQL/schemas[Schemas] for more information about schemas in Ignite.
  
  Note that the CREATE TABLE operation is synchronous and blocks the execution of other DDL commands that are issued while CREATE TABLE is still in progress. The execution of DML commands is not affected and can be performed in parallel.
  
  If you wish to access the data using the key-value APIs, then setting the `CACHE_NAME`, `KEY_TYPE`, and `VALUE_TYPE` parameters may be useful for the following reasons:
  
  - When the CREATE TABLE command is executed, the name of the cache is generated with the following format- `SQL_{SCHEMA_NAME}_{TABLE}`. Use the CACHE_NAME parameter to override the default name.
  - Additionally, the command creates two new binary types - for the key and value respectively. Ignite generates the names of the types randomly including a UUID string. This complicates the usage of these 'types' from a non-SQL API. Use KEY_TYPE and VALUE_TYPE to override the names with custom ones corresponding to your business model objects.
  
  Read more about the database architecture on the link:SQL/sql-introduction[SQL Introduction] page.
  
  
  Examples:
  
  Create Person table:
  
  [source,sql]
  ----
  
negative.code: sets the write synchronization mode for the underlying cache. If neither this nor the `TEMPLATE` parameter is set, then the cache is created with `FULL_SYNC` mode enabled.
  ** `CACHE_GROUP=<group name>` - specifies the link:configuring-caches/cache-groups[group name] the underlying cache belongs to.
  ** `AFFINITY_KEY=<affinity key column name>` - specifies an link:data-modeling/affinity-collocation[affinity key] name which is a column of the `PRIMARY KEY` constraint.
  ** `CACHE_NAME=<custom name of the new cache>` - the name of the underlying cache created by the command,
  or the `SQL_{SCHEMA_NAME}_{TABLE}` format will be used if the parameter not specified.
  ** `DATA_REGION=<existing data region name>` - name of the link:memory-configuration/data-regions[data region] where table entries should be stored. By default, Ignite stores all the data in a default region.
  ** `KEY_TYPE=<custom name of the key type>` - sets the name of the custom key type that is used from the key-value APIs in Ignite. The name should correspond to a Java, .NET, or C++ class, or it can be a random one if link:data-modeling/data-modeling#binary-object-format[BinaryObjects] is used instead of a custom class. The number of fields and their types in the custom key type has to correspond to the `PRIMARY KEY`. Refer to the <<Description>> section below for more details.
  ** `VALUE_TYPE=<custom name of the value type of the new cache>` - sets the name of a custom value type that is used from the key-value and other non-SQL APIs in Ignite. The name should correspond to a Java, .NET, or C++ class, or it can be a random one if
  