2020-10-30 14:08:56 -04:00
---
2022-05-31 11:09:02 -04:00
stage: Data Stores
2020-11-17 10:09:28 -05:00
group: Database
2020-11-26 01:09:20 -05:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-10-30 14:08:56 -04:00
---
2021-02-24 16:11:16 -05:00
# Update multiple database objects
2020-10-12 02:08:53 -04:00
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32921) in GitLab 13.5.
2021-02-24 16:11:16 -05:00
You can update multiple database objects with new values for one or more columns.
One method is to use `Relation#update_all` :
2020-10-12 02:08:53 -04:00
```ruby
user.issues.open.update_all(due_date: 7.days.from_now) # (1)
user.issues.update_all('relative_position = relative_position + 1') # (2)
```
2021-02-24 16:11:16 -05:00
If you cannot express the update as either a static value (1) or as a calculation (2),
use `UPDATE FROM` to express the need to update multiple rows with distinct values
in a single query. Create a temporary table, or a Common Table Expression (CTE),
and use it as the source of the updates:
2020-10-12 02:08:53 -04:00
```sql
with updates(obj_id, new_title, new_weight) as (
values (1 :: integer, 'Very difficult issue' :: text, 8 :: integer),
(2, 'Very easy issue', 1)
)
2020-10-20 02:09:03 -04:00
update issues
2020-10-12 02:08:53 -04:00
set title = new_title, weight = new_weight
from updates
where id = obj_id
```
2021-02-24 16:11:16 -05:00
You can't express this in ActiveRecord, or by dropping down to [Arel ](https://api.rubyonrails.org/v6.1.0/classes/Arel.html ),
because the `UpdateManager` does not support `update from` . However, we supply
an abstraction to help you generate these kinds of updates: `Gitlab::Database::BulkUpdate` .
This abstraction constructs queries like the previous example, and uses
binding parameters to avoid SQL injection.
2020-10-12 02:08:53 -04:00
## Usage
2021-02-24 16:11:16 -05:00
To use `Gitlab::Database::BulkUpdate` , we need:
2020-10-12 02:08:53 -04:00
2021-02-24 16:11:16 -05:00
- The list of columns to update.
- A mapping from the object (or ID) to the new values to set for that object.
- A way to determine the table for each object.
2020-10-12 02:08:53 -04:00
2021-02-24 16:11:16 -05:00
For example, we can express the example query in a way that determines the
table by calling `object.class.table_name` :
2020-10-12 02:08:53 -04:00
```ruby
issue_a = Issue.find(..)
issue_b = Issue.find(..)
# Issues a single query:
::Gitlab::Database::BulkUpdate.execute(%i[title weight], {
issue_a => { title: 'Very difficult issue', weight: 8 },
issue_b => { title: 'Very easy issue', weight: 1 }
})
```
2021-02-24 16:11:16 -05:00
You can even pass heterogeneous sets of objects, if the updates all make sense
2020-10-12 02:08:53 -04:00
for them:
```ruby
issue_a = Issue.find(..)
issue_b = Issue.find(..)
merge_request = MergeRequest.find(..)
# Issues two queries
::Gitlab::Database::BulkUpdate.execute(%i[title], {
issue_a => { title: 'A' },
issue_b => { title: 'B' },
merge_request => { title: 'B' }
})
```
2021-02-24 16:11:16 -05:00
If your objects do not return the correct model class, such as if they are part
of a union, then specify the model class explicitly in a block:
2020-10-12 02:08:53 -04:00
```ruby
bazzes = params
objects = Foo.from_union([
Foo.select("id, 'foo' as object_type").where(quux: true),
Bar.select("id, 'bar' as object_type").where(wibble: true)
])
# At this point, all the objects are instances of Foo, even the ones from the
# Bar table
2020-10-20 23:08:45 -04:00
mapping = objects.to_h { |obj| [obj, bazzes[obj.id]] }
2020-10-20 02:09:03 -04:00
2020-10-12 02:08:53 -04:00
# Issues at most 2 queries
::Gitlab::Database::BulkUpdate.execute(%i[baz], mapping) do |obj|
obj.object_type.constantize
end
```
## Caveats
2021-02-24 16:11:16 -05:00
This tool is **very low level** , and operates directly on the raw column
values. You should consider these issues if you implement it:
- Enumerations and state fields must be translated into their underlying
representations.
- Nested associations are not supported.
- No validations or hooks are called.