summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/development/database/iterating_tables_in_batches.md52
-rw-r--r--doc/development/merge_request_concepts/diffs/frontend.md38
-rw-r--r--doc/update/removals.md6
-rw-r--r--doc/user/project/repository/branches/index.md2
4 files changed, 65 insertions, 33 deletions
diff --git a/doc/development/database/iterating_tables_in_batches.md b/doc/development/database/iterating_tables_in_batches.md
index 6357bed8b00..ddba5b377d7 100644
--- a/doc/development/database/iterating_tables_in_batches.md
+++ b/doc/development/database/iterating_tables_in_batches.md
@@ -465,6 +465,58 @@ Issue.each_batch(of: 1000) do |relation|
end
```
+### Counting records
+
+For tables with a large amount of data, counting records through queries can result
+in timeouts. The `EachBatch` module provides an alternative way to iteratively count
+records. The downside of using `each_batch` is the extra count query which is executed
+on the yielded relation object.
+
+The `each_batch_count` method is a more efficient approach that eliminates the need
+for the extra count query. By invoking this method, the iteration process can be
+paused and resumed as needed. This feature is particularly useful in situations
+where error budget violations are triggered after five minutes, such as when performing
+counting operations within Sidekiq workers.
+
+To illustrate, counting records using `EachBatch` involves invoking an additional
+count query as follows:
+
+```ruby
+count = 0
+
+Issue.each_batch do |relation|
+ count += relation.count
+end
+
+puts count
+```
+
+On the other hand, the `each_batch_count` method enables the counting process to be
+performed more efficiently (counting is part of the iteration query) without invoking
+an extra count query:
+
+```ruby
+count, _last_value = Issue.each_batch_count # last value can be ignored here
+```
+
+Furthermore, the `each_batch_count` method allows the counting process to be paused
+and resumed at any point. This capability is demonstrated in the following code snippet:
+
+```ruby
+stop_at = Time.current + 3.minutes
+
+count, last_value = Issue.each_batch_count do
+ Time.current > stop_at # condition for stopping the counting
+end
+
+# Continue the counting later
+stop_at = Time.current + 3.minutes
+
+count, last_value = Issue.each_batch_count(last_count: count, last_value: last_value) do
+ Time.current > stop_at
+end
+```
+
### `EachBatch` vs `BatchCount`
When adding new counters for Service Ping, the preferred way to count records is using the
diff --git a/doc/development/merge_request_concepts/diffs/frontend.md b/doc/development/merge_request_concepts/diffs/frontend.md
index 6bd6d80af94..ff163050e1f 100644
--- a/doc/development/merge_request_concepts/diffs/frontend.md
+++ b/doc/development/merge_request_concepts/diffs/frontend.md
@@ -84,40 +84,9 @@ The most important part of the metadata response is the diff file names. This da
app to render the file browser inside of the diffs app, without waiting for all batch diffs
requests to complete.
-When the metadata response is received, the diff file data gets sent to a web worker. The web worker
-exists to allow for this data, which for larger merge requests could be huge, to be processed off
-the main thread. Processing this data involves getting the data into the correct structure
+When the metadata response is received, the diff file data is processed into the correct structure
that the frontend requires to render the file browser in either tree view or list view.
-```mermaid
-graph TD
- A[fetchDiffFilesMeta]
- B[Create web worker]
- C[Fetch data]
- D[SET_DIFF_METADATA]
- E[Post worker data]
- F[Worker message event listener]
- K[SET_TREE_DATA]
-
- G[TreeWorker]
- H[onMessage]
- I[generateTreeList]
- J[postMessage sortTree]
-
- A -->B
- E -->F
- B -->C
- C -->D
- D -->E
-
- G -->H
- H -->I
- I -->J
- J -->F
-
- F -->K
-```
-
The structure for this file object is:
```javascript
@@ -128,6 +97,11 @@ The structure for this file object is:
"type": "",
"tree": [],
"changed": true,
+ "diffLoaded": false,
+ "filePaths": {
+ "old": file.old_path,
+ "new": file.new_path
+ },
"tempFile": false,
"deleted": false,
"fileHash": "",
diff --git a/doc/update/removals.md b/doc/update/removals.md
index 248d03cbbcb..b9122bd6b52 100644
--- a/doc/update/removals.md
+++ b/doc/update/removals.md
@@ -34,6 +34,12 @@ For removal reviewers (Technical Writers only):
https://about.gitlab.com/handbook/marketing/blog/release-posts/#update-the-removals-doc
-->
+## Removed in 15.11
+
+### Exporting and importing groups and projects in JSON format is no longer supported
+
+Before version 14.0, GitLab produced project file exports in JSON format. To support transitions, importing JSON-formatted group and project file exports was still possible if you configured the relevant feature flags. As of GitLab 15.11, importing a JSON-formatted group and project file export is no longer supported.
+
## Removed in 15.9
### Live Preview no longer available in the Web IDE
diff --git a/doc/user/project/repository/branches/index.md b/doc/user/project/repository/branches/index.md
index ef625739956..4382d666ac6 100644
--- a/doc/user/project/repository/branches/index.md
+++ b/doc/user/project/repository/branches/index.md
@@ -82,7 +82,7 @@ and their protection methods:
Prerequisites:
-- You must have at least the Developer role in the project.
+- You must have at least the Maintainer role in the project.
To view the **Branch rules overview** list: