Silberfuchs1 commented on a change in pull request #9545:
URL: https://github.com/apache/ignite/pull/9545#discussion_r741023785
##########
File path: docs/_docs/code-deployment/peer-class-loading.adoc
##########
@@ -28,12 +28,12 @@ If you develop C# and .NET applications, then refer to the
link:net-specific/net
page for details on how to set up and use the peer-class-loading feature with
that type of applications.
====
-For example, when link:key-value-api/using-scan-queries[querying data] with a
custom transformer, you only need to define your tasks on the client node that
initiates the computation, and Ignite loads the classes to the server nodes.
+For example, when link:key-value-api/using-cache-queries[querying data] with a
custom transformer, you only need to define your tasks on the client node that
initiates the computation, and Ignite loads the classes to the server nodes.
Review comment:
only --> just. You can use both, but just sounds better in this
situation.
loads --> will upload
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
+====
+
+Index queries perform over distributed indexes and retrieve cache entries that
match the specified query. `QueryCursor`
Review comment:
Index queries perform over distributed indexes --> Index queries are
performed over distributed indexes
##########
File path: docs/_docs/thin-clients/java-thin-client.adoc
##########
@@ -132,7 +132,7 @@ include::{sourceCodeFile}[tag=key-value-operations,indent=0]
-------------------------------------------------------------------------------
=== Executing Scan Queries
-Use the `ScanQuery<K, V>` class to get a set of entries that satisfy a given
condition. The thin client sends the query to the cluster node where it is
executed as a normal link:key-value-api/using-scan-queries[scan query].
+Use the `ScanQuery<K, V>` class to get a set of entries that satisfy a given
condition. The thin client sends the query to the cluster node where it is
executed as a regular link:key-value-api/using-cache-queries[scan query].
The query condition is specified by an `IgniteBiPredicate<K, V>` object that
is passed to the query constructor as an argument. The predicate is applied on
the server side. If you don't provide any predicate, the query returns all
cache entries.
Review comment:
If you don't provide any predicate --> If there is no predicate provided
##########
File path:
modules/core/src/main/java/org/apache/ignite/cache/query/IndexQuery.java
##########
@@ -29,12 +29,15 @@
import org.jetbrains.annotations.Nullable;
/**
- * Index query runs over internal index structure and returns cache entries
for index rows.
+ * Index queries perform over distributed indexes and retrieve cache entries
that match the specified criteria.
+ * {@code QueryCursor} delivers sorted cache entries by the order defined for
queried index.
*
* {@code IndexQuery} has to be initialized with cache value class or type.
The algorithm of discovering index is as following:
* 1. If {@link #idxName} is set, then use it.
* 2. If {@link #idxName} is not set, then find an index that matches criteria
fields.
* 3. If neither of {@link #idxName} or {@link #setCriteria(List)} used, then
perform index scan over PK index for specified Value type.
Review comment:
. If neither of {@link #idxName} or {@link #setCriteria(List)} used,
then perform index scan over PK index for specified Value type. --> . If
neither {@link #idxName}, nor {@link #setCriteria(List)} is used, then perform
index scan over PK index for specified Value type.
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
Review comment:
Questions or bug reports are welcome, please share it with
[email protected]. --> Please send your questions and bug reports to
[email protected].
##########
File path: docs/_docs/events/events.adoc
##########
@@ -128,7 +128,7 @@ Cache events are also generated when you use DML commands.
| EVT_CACHE_OBJECT_READ
| An object is read from a cache.
-This event is not emitted when you use
link:key-value-api/using-scan-queries[scan queries] (use <<Cache Query Events>>
to monitor scan queries).
+This event is not emitted when you use
link:key-value-api/using-cache-queries[scan queries] (use <<Cache Query
Events>> to monitor scan queries).
| The node where read operation is executed.
It can be either the primary or backup node (the latter case is only possible
when link:configuring-caches/configuration-overview#readfrombackup[reading from
backups is enabled]).
Review comment:
is only possible when
link:configuring-caches/configuration-overview#readfrombackup[reading from
backups is enabled]). maybe --> is only possible when
link:configuring-caches/configuration-overview#readfrombackup[reading from
backups] is enabled).
##########
File path: docs/_docs/events/events.adoc
##########
@@ -128,7 +128,7 @@ Cache events are also generated when you use DML commands.
| EVT_CACHE_OBJECT_READ
| An object is read from a cache.
-This event is not emitted when you use
link:key-value-api/using-scan-queries[scan queries] (use <<Cache Query Events>>
to monitor scan queries).
+This event is not emitted when you use
link:key-value-api/using-cache-queries[scan queries] (use <<Cache Query
Events>> to monitor scan queries).
Review comment:
same as Line 108
##########
File path: docs/_docs/distributed-computing/collocated-computations.adoc
##########
@@ -105,7 +105,7 @@ tab:C++[unsupported]
====
[discrete]
=== Performance Considerations
-Colocated computations yield performance benefits when the amount of the data
you want to process is sufficiently large. In some cases, when the amount of
data is small, a link:key-value-api/using-scan-queries[scan query] may perform
better.
+Colocated computations yield performance benefits when the amount of the data
you want to process is sufficiently large. In some cases, when the amount of
data is small, a link:key-value-api/using-cache-queries[scan query] may perform
better.
Review comment:
the link is about cache queries, but the alt text is still 'scan query'
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
+====
+
+Index queries perform over distributed indexes and retrieve cache entries that
match the specified query. `QueryCursor`
+delivers sorted cache entries by the order defined for queried index.
`IndexQuery` can be used if a low amount of data
+match filtering criteria. For such cases, `ScanQuery` usage is not optimal: it
firstly extracts all cache entries and
+then applies a filter on them. `IndexQuery` relies on index tree structure and
filters most of the entries without extracting.
Review comment:
then applies a filter on them. --> then applies a filter to them.
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
+====
+
+Index queries perform over distributed indexes and retrieve cache entries that
match the specified query. `QueryCursor`
+delivers sorted cache entries by the order defined for queried index.
`IndexQuery` can be used if a low amount of data
+match filtering criteria. For such cases, `ScanQuery` usage is not optimal: it
firstly extracts all cache entries and
+then applies a filter on them. `IndexQuery` relies on index tree structure and
filters most of the entries without extracting.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQry,indent=0]
+----
+
+Index query criteria are defined in `IndexQueryCriteriaBuilder`. The goal of
the criteria is to build a valid range to
+traverse the index tree. For this reason, criteria fields have to match the
specified index. For example, if there is an
+index defined with (A, B) set, then valid criteria sets are (A) and (A, B).
Criteria with the single (B) field are invalid
+because the field (B) is not a prefix set of the specified index fields, and
it's impossible to build a narrow index range
+with it.
+
+[NOTE]
+====
+Criteria are joint by the AND operator. Also it is possible to use multiple
criteria for the same field.
Review comment:
joined
Also it is possible --> it is also possible
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
+====
+
+Index queries perform over distributed indexes and retrieve cache entries that
match the specified query. `QueryCursor`
+delivers sorted cache entries by the order defined for queried index.
`IndexQuery` can be used if a low amount of data
+match filtering criteria. For such cases, `ScanQuery` usage is not optimal: it
firstly extracts all cache entries and
Review comment:
match --> matches
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
+====
+
+Index queries perform over distributed indexes and retrieve cache entries that
match the specified query. `QueryCursor`
+delivers sorted cache entries by the order defined for queried index.
`IndexQuery` can be used if a low amount of data
+match filtering criteria. For such cases, `ScanQuery` usage is not optimal: it
firstly extracts all cache entries and
+then applies a filter on them. `IndexQuery` relies on index tree structure and
filters most of the entries without extracting.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQry,indent=0]
+----
+
+Index query criteria are defined in `IndexQueryCriteriaBuilder`. The goal of
the criteria is to build a valid range to
+traverse the index tree. For this reason, criteria fields have to match the
specified index. For example, if there is an
+index defined with (A, B) set, then valid criteria sets are (A) and (A, B).
Criteria with the single (B) field are invalid
+because the field (B) is not a prefix set of the specified index fields, and
it's impossible to build a narrow index range
+with it.
+
+[NOTE]
+====
+Criteria are joint by the AND operator. Also it is possible to use multiple
criteria for the same field.
+====
+
+[source,java]
+----
+include::{javaFile}[tag=idxQryMultipleCriteria,indent=0]
+----
+
+The index name is an optional parameter. In this case, Ignite tries to figure
out the index by self by specified criteria fields.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQryNoIdxName,indent=0]
+----
+
+For the empty criteria list, a full scan of the specified index performs. If
also index name isn't specified, then the
+PrimaryKey index is used.
+
+=== Additional filtering
+
+`IndexQuery` also supports an optional predicate the same as `ScanQuery` have.
It's suitable for additional cache entry
Review comment:
`IndexQuery` also supports an optional predicate the same as `ScanQuery`
have. --> `IndexQuery` also supports an optional predicate, the same as
`ScanQuery` has.
##########
File path: examples/src/main/java/org/apache/ignite/examples/model/Person.java
##########
@@ -51,7 +54,7 @@
public String resume;
/** Salary (indexed). */
- @QuerySqlField(index = true)
+ @QuerySqlField(index = true, orderedGroups = @QuerySqlField.Group(name =
ORG_SALARY_IDX, order = 1))
public double salary;
/** Custom cache key to guarantee that person is always collocated with
its organization. */
Review comment:
'collocated' was previously spelled as 'colocated'. Please review.
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
+====
+
+Index queries perform over distributed indexes and retrieve cache entries that
match the specified query. `QueryCursor`
+delivers sorted cache entries by the order defined for queried index.
`IndexQuery` can be used if a low amount of data
+match filtering criteria. For such cases, `ScanQuery` usage is not optimal: it
firstly extracts all cache entries and
+then applies a filter on them. `IndexQuery` relies on index tree structure and
filters most of the entries without extracting.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQry,indent=0]
+----
+
+Index query criteria are defined in `IndexQueryCriteriaBuilder`. The goal of
the criteria is to build a valid range to
+traverse the index tree. For this reason, criteria fields have to match the
specified index. For example, if there is an
+index defined with (A, B) set, then valid criteria sets are (A) and (A, B).
Criteria with the single (B) field are invalid
+because the field (B) is not a prefix set of the specified index fields, and
it's impossible to build a narrow index range
+with it.
+
+[NOTE]
+====
+Criteria are joint by the AND operator. Also it is possible to use multiple
criteria for the same field.
+====
+
+[source,java]
+----
+include::{javaFile}[tag=idxQryMultipleCriteria,indent=0]
+----
+
+The index name is an optional parameter. In this case, Ignite tries to figure
out the index by self by specified criteria fields.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQryNoIdxName,indent=0]
+----
+
+For the empty criteria list, a full scan of the specified index performs. If
also index name isn't specified, then the
+PrimaryKey index is used.
+
+=== Additional filtering
+
+`IndexQuery` also supports an optional predicate the same as `ScanQuery` have.
It's suitable for additional cache entry
+filtering in such cases when a filter doesn't match an index tree range. For
example, it contains some logic, the "OR"
+operations, or fields that aren't part of the index.
Review comment:
that aren't part --> that are not the part
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
+====
+
+Index queries perform over distributed indexes and retrieve cache entries that
match the specified query. `QueryCursor`
+delivers sorted cache entries by the order defined for queried index.
`IndexQuery` can be used if a low amount of data
+match filtering criteria. For such cases, `ScanQuery` usage is not optimal: it
firstly extracts all cache entries and
+then applies a filter on them. `IndexQuery` relies on index tree structure and
filters most of the entries without extracting.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQry,indent=0]
+----
+
+Index query criteria are defined in `IndexQueryCriteriaBuilder`. The goal of
the criteria is to build a valid range to
+traverse the index tree. For this reason, criteria fields have to match the
specified index. For example, if there is an
+index defined with (A, B) set, then valid criteria sets are (A) and (A, B).
Criteria with the single (B) field are invalid
+because the field (B) is not a prefix set of the specified index fields, and
it's impossible to build a narrow index range
+with it.
+
+[NOTE]
+====
+Criteria are joint by the AND operator. Also it is possible to use multiple
criteria for the same field.
+====
+
+[source,java]
+----
+include::{javaFile}[tag=idxQryMultipleCriteria,indent=0]
+----
+
+The index name is an optional parameter. In this case, Ignite tries to figure
out the index by self by specified criteria fields.
Review comment:
self --> itself
by specified --> using specified
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
+====
+
+Index queries perform over distributed indexes and retrieve cache entries that
match the specified query. `QueryCursor`
+delivers sorted cache entries by the order defined for queried index.
`IndexQuery` can be used if a low amount of data
+match filtering criteria. For such cases, `ScanQuery` usage is not optimal: it
firstly extracts all cache entries and
+then applies a filter on them. `IndexQuery` relies on index tree structure and
filters most of the entries without extracting.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQry,indent=0]
+----
+
+Index query criteria are defined in `IndexQueryCriteriaBuilder`. The goal of
the criteria is to build a valid range to
+traverse the index tree. For this reason, criteria fields have to match the
specified index. For example, if there is an
+index defined with (A, B) set, then valid criteria sets are (A) and (A, B).
Criteria with the single (B) field are invalid
+because the field (B) is not a prefix set of the specified index fields, and
it's impossible to build a narrow index range
+with it.
+
+[NOTE]
+====
+Criteria are joint by the AND operator. Also it is possible to use multiple
criteria for the same field.
+====
+
+[source,java]
+----
+include::{javaFile}[tag=idxQryMultipleCriteria,indent=0]
+----
+
+The index name is an optional parameter. In this case, Ignite tries to figure
out the index by self by specified criteria fields.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQryNoIdxName,indent=0]
+----
+
+For the empty criteria list, a full scan of the specified index performs. If
also index name isn't specified, then the
Review comment:
performs --> is performed
If also index name isn't specified --> If index name is also not specified
##########
File path:
modules/core/src/main/java/org/apache/ignite/cache/query/IndexQuery.java
##########
@@ -29,12 +29,15 @@
import org.jetbrains.annotations.Nullable;
/**
- * Index query runs over internal index structure and returns cache entries
for index rows.
+ * Index queries perform over distributed indexes and retrieve cache entries
that match the specified criteria.
Review comment:
perform ---> are performed
##########
File path:
modules/core/src/main/java/org/apache/ignite/cache/query/IndexQuery.java
##########
@@ -29,12 +29,15 @@
import org.jetbrains.annotations.Nullable;
/**
- * Index query runs over internal index structure and returns cache entries
for index rows.
+ * Index queries perform over distributed indexes and retrieve cache entries
that match the specified criteria.
+ * {@code QueryCursor} delivers sorted cache entries by the order defined for
queried index.
*
* {@code IndexQuery} has to be initialized with cache value class or type.
The algorithm of discovering index is as following:
Review comment:
as following --> as follows
##########
File path: docs/_docs/key-value-api/using-cache-queries.adoc
##########
@@ -118,7 +119,64 @@
include::code-snippets/cpp/src/scan_query.cpp[tag=set-local,indent=0]
----
--
+== Executing Index Queries
+
+[WARNING]
+====
+[discrete]
+Experimental API. Introduced since Apache Ignite 2.12. Only Java API is
supported. Questions or bug reports are welcome,
+please share it with [email protected].
+====
+
+Index queries perform over distributed indexes and retrieve cache entries that
match the specified query. `QueryCursor`
+delivers sorted cache entries by the order defined for queried index.
`IndexQuery` can be used if a low amount of data
+match filtering criteria. For such cases, `ScanQuery` usage is not optimal: it
firstly extracts all cache entries and
+then applies a filter on them. `IndexQuery` relies on index tree structure and
filters most of the entries without extracting.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQry,indent=0]
+----
+
+Index query criteria are defined in `IndexQueryCriteriaBuilder`. The goal of
the criteria is to build a valid range to
+traverse the index tree. For this reason, criteria fields have to match the
specified index. For example, if there is an
+index defined with (A, B) set, then valid criteria sets are (A) and (A, B).
Criteria with the single (B) field are invalid
+because the field (B) is not a prefix set of the specified index fields, and
it's impossible to build a narrow index range
+with it.
+
+[NOTE]
+====
+Criteria are joint by the AND operator. Also it is possible to use multiple
criteria for the same field.
+====
+
+[source,java]
+----
+include::{javaFile}[tag=idxQryMultipleCriteria,indent=0]
+----
+
+The index name is an optional parameter. In this case, Ignite tries to figure
out the index by self by specified criteria fields.
+
+[source,java]
+----
+include::{javaFile}[tag=idxQryNoIdxName,indent=0]
+----
+
+For the empty criteria list, a full scan of the specified index performs. If
also index name isn't specified, then the
+PrimaryKey index is used.
+
+=== Additional filtering
+
+`IndexQuery` also supports an optional predicate the same as `ScanQuery` have.
It's suitable for additional cache entry
+filtering in such cases when a filter doesn't match an index tree range. For
example, it contains some logic, the "OR"
Review comment:
in such cases --> in cases
--
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]
