ISPN-DOC Document remaining indexing & query features #10788
Conversation
fax4ever
commented
Apr 5, 2023
•
fax4ever
commented
- Document update index schema
- Document BigDecimal and BigInteger Ickle queries
- All the rest is in WIP:ISPN-14008 Docs indexing annotations #10785
fax4ever
changed the title
fax4ever
changed the title
|
|
||
| [source,options="nowrap",subs=attributes+] | ||
| ---- | ||
| POST /v2/caches/{cacheName}/search/indexes?action=mass-index | ||
| POST /v2/caches/{cacheName}/search/indexes?action=reindex |
There was a problem hiding this comment.
@fax4ever I saw that mass-index is deprecated. Is this ok?
| Rebuilding indexes can take a long time to complete because the process takes place for all data in the grid. | ||
| While the rebuild operation is in progress, queries might also return fewer results. | ||
|
|
||
| [NOTE] |
There was a problem hiding this comment.
@wfink mentioned this information. I'm not sure if it applies to reindexing and also updating indexes.
There was a problem hiding this comment.
not sure what you mean with reindex vs. updating index.
To me reindex is to delete and create a new one - because every entry changed because of config
updating index is to change one entry because the data of it changed (which is the ongoing work)
|
@fax4ever thank you so much for the docs. I added some docs suggestions. I'll review Querying ProtoStream Common Types when I'm back on Tuesday. |
| The alternative to reindex is the update index schema, which allows you to acquire some schema changes without touching the preexisting index data. | ||
| Operation is much faster, but it is not applicable to all the changes: | ||
| = Updating index schema | ||
| Update index schema operation lets you acquire additional schema changes without downtime. |
There was a problem hiding this comment.
\without downtime\with a minimal downtime\s
|
|
||
| [IMPORTANT] | ||
| ==== | ||
| Update index schema operation can be used only if we have done only additive changes, meaning that preexisting fields shouldn't be | ||
| affected by the changes. | ||
| When you change definitions of indexed types or analyzers or when you delete them, you must rebuild the index. |
There was a problem hiding this comment.
I am not sure if it is the same concept. What I wanted to stress here is the fact that using this function is supposed to be done only if the changes on the schema do not affect pre-existing indexed fields.
| = Updating index schema | ||
| Update index schema operation lets you acquire additional schema changes without downtime. | ||
| When the schema changes don't affect the existing schema model, you can update the index schema without removing and recreating previously indexed data. | ||
| Updating index schema is much faster than rebuilding the index but you can update schema only when your changes does not affect existing index schema. |
There was a problem hiding this comment.
I would say when your changes do not affect pre-existing indexed fields.
| == Re-indexing Data | ||
| Re-index all data in caches with `POST` requests and the `?action=mass-index` parameter. | ||
| == Rebuilding indexes | ||
| When you change existing Protobuf schema definition at runtime or when the index is persistent, you must reindex the data in the index. |
There was a problem hiding this comment.
I'm not sure about the sentence:
when the index is persistent, you must reindex the data in the index.
I would write something more general:
or in case of any kind of misalignment between the cache data and the indexes
| == Update index schema | ||
| Update the index schema in caches with `POST` requests and the `?action=updateSchema` parameter. | ||
| == Updating index schema | ||
| Update index schema operation lets you acquire additional schema changes without downtime. |
There was a problem hiding this comment.
I would write with a minimal downtime
| [IMPORTANT] | ||
| ==== | ||
| When you change existing Protobuf schema definition, you must reindex the data in the index. | ||
| Rebuilding indexes has impact on performance and can take a long time to complete because the process takes place for all data in the grid. | ||
| While the rebuild operation is in progress, queries might also return fewer results. | ||
| ==== | ||
|
|
There was a problem hiding this comment.
It is possible that the change can not have an impact on the indexes, e.g.: if the related caches are not indexed.
I would write something more general, such as:
If the change has an impact on some indexed caches, these should be aligned if we want the change to be visible for them. To align the index schema is it possible to reindex (valid for the general case) or update the index schema (only if the changes do not touch pre-existing fields).
|
HI @fax4ever I made some updates based on your feedback. I'm still working on the BigInteger and BigDecimal. Will have updates tomorrow |
|
@fax4ever let me know what you think about the updates. |
|
The changes looks great, thanks @dvagnero. |
