alex-plekhanov commented on code in PR #10040:
URL: https://github.com/apache/ignite/pull/10040#discussion_r882630823
##########
docs/_docs/sql-reference/ddl.adoc:
##########
@@ -84,28 +114,58 @@ CREATE TABLE IF NOT EXISTS Person (
age int,
company varchar,
PRIMARY KEY (id, city_id)
-) WITH "template=partitioned,backups=1,affinity_key=city_id,
key_type=PersonKey, value_type=MyPerson";
+) WITH
"template=partitioned,backups=1,affinity_key=city_id,CACHE_NAME=Person,KEY_TYPE=PersonKey,VALUE_TYPE=PersonValue";
----
-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.
+=== CREATE TABLE Using non-UpperCase Columns Example
Review Comment:
`non-UpperCase` -> `non-upper case`?
##########
docs/_docs/sql-reference/ddl.adoc:
##########
@@ -84,28 +114,58 @@ CREATE TABLE IF NOT EXISTS Person (
age int,
company varchar,
PRIMARY KEY (id, city_id)
-) WITH "template=partitioned,backups=1,affinity_key=city_id,
key_type=PersonKey, value_type=MyPerson";
+) WITH
"template=partitioned,backups=1,affinity_key=city_id,CACHE_NAME=Person,KEY_TYPE=PersonKey,VALUE_TYPE=PersonValue";
----
-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.
+=== CREATE TABLE Using non-UpperCase Columns Example
+
+Both of Ignite’s SQL engines (H2 and Calcite) all unquoted identifiers, names
of a table columns convert to upper case
Review Comment:
Here we shouldn't refer to engines (H2 and Calcite), something like
'Ignite's SQL parser converts all unquted identifiers to upper case', I think,
will be better.
##########
docs/_docs/sql-reference/ddl.adoc:
##########
@@ -49,31 +58,52 @@ Parameters:
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.
+** `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
link:data-modeling/data-modeling#binary-object-format[BinaryObjects] is used
instead of a custom class. The value type should include all the columns
defined in the CREATE TABLE command except for those listed in the `PRIMARY
KEY` constraint. Refer to the <<Description>> section below for more details.
** `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.
+Read more about the database architecture on the link:SQL/sql-introduction[SQL
Introduction] page.
-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:
+=== CREATE TABLE Example
Review Comment:
There is some theory inside "example" subsections. I think it's better to
move theory outside of subsection or rename subtitle and remove "example" word.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
