The UPDATE
command changes row-wise attribute values of existing documents in a specified table with new values. Note that you can't update the contents of a fulltext field or a columnar attribute. If there's such a need, use REPLACE.
Attribute updates are supported for RT, PQ, and plain tables. All attribute types can be updated as long as they are stored in the row-wise storage.
Note that the document ID cannot be updated.
It's important to be aware that updating an attribute disables its secondary index. If maintaining secondary index continuity is critical, consider fully or partially replacing the document instead.
Read more about UPDATE
vs. partial REPLACE
here.
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
UPDATE products SET enabled=0 WHERE id=10;
Query OK, 1 row affected (0.00 sec)
Multiple attributes can be updated in a single statement. Example:
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
UPDATE products
SET price=100000000000,
coeff=3465.23,
tags1=(3,6,4),
tags2=()
WHERE MATCH('phone') AND enabled=1;
Query OK, 148 rows affected (0.0 sec)
When assigning out-of-range values to 32-bit attributes, they will be trimmed to their lower 32 bits without a prompt. For example, if you try to update the 32-bit unsigned int with a value of 4294967297, the value of 1 will actually be stored, because the lower 32 bits of 4294967297 (0x100000001 in hex) amount to 1 (0x00000001 in hex).
UPDATE
can be used to perform partial JSON updates on numeric data types or arrays of numeric data types. Just make sure you don't update an integer value with a float value as it will be rounded off.
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
insert into products (id, title, meta) values (1,'title','{"tags":[1,2,3]}');
update products set meta.tags[0]=100 where id=1;
Query OK, 1 row affected (0.00 sec)
Query OK, 1 row affected (0.00 sec)
Updating other data types or changing property type in a JSON attribute requires a full JSON update.
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
insert into products values (1,'title','{"tags":[1,2,3]}');
update products set data='{"tags":["one","two","three"]}' where id=1;
Query OK, 1 row affected (0.00 sec)
Query OK, 1 row affected (0.00 sec)
When using replication, the table name should be prepended with cluster_name:
(in SQL) so that updates will be propagated to all nodes in the cluster. For queries via HTTP, you should set a cluster
property. See setting up replication for more information.
{
"cluster":"nodes4",
"index":"test",
"id":1,
"doc":
{
"gid" : 100,
"price" : 1000
}
}
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
update weekly:posts set enabled=0 where id=1;
Here is the syntax for the SQL UPDATE
statement:
UPDATE table SET col1 = newval1 [, ...] WHERE where_condition [OPTION opt_name = opt_value [, ...]] [FORCE|IGNORE INDEX(id)]
where_condition
has the same syntax as in the SELECT statement.
Multi-value attribute value sets must be specified as comma-separated lists in parentheses. To remove all values from a multi-value attribute, just assign ()
to it.
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
UPDATE products SET tags1=(3,6,4) WHERE id=1;
UPDATE products SET tags1=() WHERE id=1;
Query OK, 1 row affected (0.00 sec)
Query OK, 1 row affected (0.00 sec)
OPTION
clause is a Manticore-specific extension that lets you control a number of per-update options. The syntax is:
OPTION <optionname>=<value> [ , ... ]
The options are the same as for the SELECT statement. Specifically for the UPDATE
statement, you can use these options:
- 'ignore_nonexistent_columns' - If set to 1, it indicates that the update will silently ignore any warnings about trying to update a column which does not exist in the current table schema. The default value is 0.
- 'strict' - This option is used in partial JSON attribute updates. By default (strict=1),
UPDATE
will result in an error if theUPDATE
query tries to perform an update on non-numeric properties. With strict=0, if multiple properties are updated and some are not allowed, theUPDATE
will not result in an error and will perform the changes only on allowed properties (with the rest being ignored). If none of theSET
changes of theUPDATE
re permitted, the command will result in an error even with strict=0.
In rare cases, Manticore's built-in query analyzer may be incorrect in understanding a query and determining whether a table by ID should be used. This can result in poor performance for queries like UPDATE ... WHERE id = 123
.
For information on how to force the optimizer to use a docid index, see Query optimizer hints.
Updates using HTTP JSON protocol are performed via the /update
endpoint. The syntax is similar to the /insert endpoint, but this time the doc
property is mandatory.
The server will respond with a JSON object stating if the operation was successful or not.
- JSON
POST /update
{
"index":"test",
"id":1,
"doc":
{
"gid" : 100,
"price" : 1000
}
}
{
"_index": "test",
"_id": 1,
"result": "updated"
}
The ID of the document that needs to be updated can be set directly using the id
property, as shown in the previous example, or you can update documents by query and apply the update to all the documents that match the query:
- JSON
POST /update
{
"index":"test",
"doc":
{
"price" : 1000
},
"query":
{
"match": { "*": "apple" }
}
}
{
"_index":"products",
"updated":1
}
The query syntax is the same as in the /search endpoint. Note that you can't specify id
and query
at the same time.
FLUSH ATTRIBUTES
The FLUSH ATTRIBUTES command flushes all in-memory attribute updates in all the active tables to disk. It returns a tag that identifies the result on-disk state, which represents the number of actual disk attribute saves performed since the server startup.
mysql> UPDATE testindex SET channel_id=1107025 WHERE id=1;
Query OK, 1 row affected (0.04 sec)
mysql> FLUSH ATTRIBUTES;
+------+
| tag |
+------+
| 1 |
+------+
1 row in set (0.19 sec)
See also attr_flush_period setting.
You can perform multiple update operations in a single call using the /bulk
endpoint. This endpoint only works with data that has Content-Type
set to application/x-ndjson
. The data should be formatted as newline-delimited JSON (NDJSON). Essentially, this means that each line should contain exactly one JSON statement and end with a newline \n
and, possibly, a \r
.
- JSON
POST /bulk
{ "update" : { "index" : "products", "id" : 1, "doc": { "price" : 10 } } }
{ "update" : { "index" : "products", "id" : 2, "doc": { "price" : 20 } } }
{
"items":
[
{
"update":
{
"_index":"products",
"_id":1,
"result":"updated"
}
},
{
"update":
{
"_index":"products",
"_id":2,
"result":"updated"
}
}
],
"errors":false
}
The /bulk
endpoint supports inserts, replaces, and deletes. Each statement begins with an action type (in this case, update
). Here's a list of the supported actions:
insert
: Inserts a document. The syntax is the same as in the /insert endpoint.create
: a synonym forinsert
replace
: Replaces a document. The syntax is the same as in the /replace.index
: a synonym forreplace
update
: Updates a document. The syntax is the same as in the /update.delete
: Deletes a document. The syntax is the same as in the /delete endpoint.
Updates by query and deletes by query are also supported.
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
POST /bulk
{ "update" : { "index" : "products", "doc": { "coeff" : 1000 }, "query": { "range": { "price": { "gte": 1000 } } } } }
{ "update" : { "index" : "products", "doc": { "coeff" : 0 }, "query": { "range": { "price": { "lt": 1000 } } } } }
{
"items":
[
{
"update":
{
"_index":"products",
"updated":1
}
},
{
"update":
{
"_index":"products",
"updated":3
}
}
],
"errors":false
}
Keep in mind that the bulk operation stops at the first query that results in an error.
attr_update_reserve=size
attr_update_reserve
is a per-table setting that determines the space reserved for blob attribute updates. This setting is optional, with a default value of 128k.
When blob attributes (MVAs, strings, JSON) are updated, their length may change. If the updated string (or MVA, or JSON) is shorter than the old one, it overwrites the old one in the .spb
file. However, if the updated string is longer, updates are written to the end of the .spb
file. This file is memory-mapped, which means resizing it may be a rather slow process, depending on the OS implementation of memory-mapped files.
To avoid frequent resizes, you can specify the extra space to be reserved at the end of the .spb
file using this option.
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
- CONFIG
create table products(title text, price float) attr_update_reserve = '1M'
attr_flush_period = 900 # persist updates to disk every 15 minutes
When updating attributes the changes are first written to in-memory copy of attributes. This setting allows to set the interval between flushing the updates to disk. It defaults to 0, which disables the periodic flushing, but flushing will still occur at normal shut-down.
Deleting documents is only supported in RT mode for the following table types:
- Real-time tables
- Percolate tables
- Distributed tables that only contain RT tables as local or remote agents.
You can delete existing documents from a table based on either their ID or certain conditions.
Also, bulk deletion is available to delete multiple documents.
Deletion of documents can be accomplished via both SQL and JSON interfaces.
For SQL, the response for a successful operation will indicate the number of rows deleted.
For JSON, the json/delete
endpoint is used. The server will respond with a JSON object indicating whether the operation was successful and the number of rows deleted.
It is recommended to use table truncation instead of deletion to delete all documents from a table, as it is a much faster operation.
In this example we delete all documents that match full-text query test document
from the table named test
:
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
mysql> SELECT * FROM TEST;
+------+------+-------------+------+
| id | gid | mva1 | mva2 |
+------+------+-------------+------+
| 100 | 1000 | 100,201 | 100 |
| 101 | 1001 | 101,202 | 101 |
| 102 | 1002 | 102,203 | 102 |
| 103 | 1003 | 103,204 | 103 |
| 104 | 1004 | 104,204,205 | 104 |
| 105 | 1005 | 105,206 | 105 |
| 106 | 1006 | 106,207 | 106 |
| 107 | 1007 | 107,208 | 107 |
+------+------+-------------+------+
8 rows in set (0.00 sec)
mysql> DELETE FROM TEST WHERE MATCH ('test document');
Query OK, 2 rows affected (0.00 sec)
mysql> SELECT * FROM TEST;
+------+------+-------------+------+
| id | gid | mva1 | mva2 |
+------+------+-------------+------+
| 100 | 1000 | 100,201 | 100 |
| 101 | 1001 | 101,202 | 101 |
| 102 | 1002 | 102,203 | 102 |
| 103 | 1003 | 103,204 | 103 |
| 104 | 1004 | 104,204,205 | 104 |
| 105 | 1005 | 105,206 | 105 |
+------+------+-------------+------+
6 rows in set (0.00 sec)
{
"_index":"test",
"deleted":2,
}
Here - deleting a document with id
equalling 1 from the table named test
:
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
mysql> DELETE FROM TEST WHERE id=1;
Query OK, 1 rows affected (0.00 sec)
{
"_index": "test",
"_id": 1,
"found": true,
"result": "deleted"
}
Here, documents with id
matching values from the table named test
are deleted:
Note that the delete forms with id=N
or id IN (X,Y)
are the fastest, as they delete documents without performing a search.
Also note that the response contains only the id of the first deleted document in the corresponding _id
field.
- SQL
- JSON
- PHP
DELETE FROM TEST WHERE id IN (1,2);
Query OK, 2 rows affected (0.00 sec)
Manticore SQL allows to use complex conditions for the DELETE
statement.
For example here we are deleting documents that match full-text query test document
and have attribute mva1
with a value greater than 206 or mva1
values 100 or 103 from table named test
:
- SQL
DELETE FROM TEST WHERE MATCH ('test document') AND ( mva1>206 or mva1 in (100, 103) );
SELECT * FROM TEST;
Query OK, 4 rows affected (0.00 sec)
+------+------+-------------+------+
| id | gid | mva1 | mva2 |
+------+------+-------------+------+
| 101 | 1001 | 101,202 | 101 |
| 102 | 1002 | 102,203 | 102 |
| 104 | 1004 | 104,204,205 | 104 |
| 105 | 1005 | 105,206 | 105 |
+------+------+-------------+------+
6 rows in set (0.00 sec)
Here is an example of deleting documents in cluster cluster
's table test
. Note that we must provide the cluster name property along with table property to delete a row from a table within a replication cluster:
- SQL
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
delete from cluster:test where id=100;
Array(
[_index] => test
[_id] => 100
[found] => true
[result] => deleted
)
You can also perform multiple delete operations in a single call using the /bulk
endpoint. This endpoint only works with data that has Content-Type
set to application/x-ndjson
. The data should be formatted as newline-delimited JSON (NDJSON). Essentially, this means that each line should contain exactly one JSON statement and end with a newline \n
and, possibly, a \r
.
- JSON
- PHP
- Python
- javascript
- Java
- C#
- TypeScript
- Go
POST /bulk
{ "delete" : { "index" : "test", "id" : 1 } }
{ "delete" : { "index" : "test", "query": { "equals": { "int_data" : 20 } } } }
{
"items":
[
{
"bulk":
{
"_index":"test",
"_id":0,
"created":0,
"deleted":2,
"updated":0,
"result":"created",
"status":201
}
}
],
"errors":false
}
Manticore supports basic transactions for deleting and inserting data into real-time and percolate tables, except when attempting to write to a distributed table which includes a real-time or percolate table. Each change to a table is first saved in an internal changeset and then actually committed to the table. By default, each command is wrapped in an individual automatic transaction, making it transparent: you simply 'insert' something and can see the inserted result after it completes, without worrying about transactions. However, this behavior can be explicitly managed by starting and committing transactions manually.
Transactions are supported for the following commands:
Transactions are not supported for:
- UPDATE (which is different from REPLACE, as it performs an in-place attribute update)
- ALTER - for updating table schema
- TRUNCATE - for emptying a real-time table
- ATTACH - for attaching a plain table to a real-time table
- CREATE - for creating a table
- DROP - for deleting a table
Please note that transactions in Manticore do not aim to provide isolation. The purpose of transactions in Manticore is to allow you to accumulate multiple writes and execute them all at once upon commit, or to roll them all back if necessary. Transactions are integrated with binary log for durability and consistency.
SET AUTOCOMMIT = {0 | 1}
SET AUTOCOMMIT
controls the autocommit mode in the active session. AUTOCOMMIT
is set to 1 by default. With the default setting, you don't have to worry about transactions, as every statement that makes any changes to any table is implicitly wrapped in a separate transaction. Setting it to 0 allows you to manage transactions manually, meaning they will not be visible until you explicitly commit them.
Transactions are limited to a single real-time or percolate table and are also limited in size. They are atomic, consistent, overly isolated, and durable. Overly isolated means that the changes are not only invisible to concurrent transactions but even to the current session itself.
START TRANSACTION | BEGIN
COMMIT
ROLLBACK
The BEGIN
statement (or its START TRANSACTION
alias) forcibly commits any pending transaction, if present, and starts a new one.
The COMMIT
statement commits the current transaction, making all its changes permanent.
The ROLLBACK
statement rolls back the current transaction, canceling all its changes.
When using one of the /bulk
JSON endpoints ( bulk insert, bulk replace, bulk delete ), you can force a batch of documents to be committed by adding an empty line after them.
insert into indexrt (id, content, title, channel_id, published) values (1, 'aa', 'blabla', 1, 10);
Query OK, 1 rows affected (0.00 sec)
select * from indexrt where id=1;
+------+------------+-----------+--------+
| id | channel_id | published | title |
+------+------------+-----------+--------+
| 1 | 1 | 10 | blabla |
+------+------------+-----------+--------+
1 row in set (0.00 sec)
The inserted value is immediately visible in the following 'select' statement.
set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
insert into indexrt (id, content, title, channel_id, published) values (3, 'aa', 'bb', 1, 1);
Query OK, 1 row affected (0.00 sec)
insert into indexrt (id, content, title, channel_id, published) values (4, 'aa', 'bb', 1, 1);
Query OK, 1 row affected (0.00 sec)
select * from indexrt where id=3;
Empty set (0.01 sec)
select * from indexrt where id=4;
Empty set (0.00 sec)
In this case, changes are NOT automatically committed. As a result, the insertions are not visible, even in the same session, since they have not been committed. Also, despite the absence of a BEGIN
statement, a transaction is implicitly started.
To make the changes visible, you need to commit the transaction:
commit;
Query OK, 0 rows affected (0.00 sec)
select * from indexrt where id=4;
+------+------------+-----------+-------+
| id | channel_id | published | title |
+------+------------+-----------+-------+
| 4 | 1 | 1 | bb |
+------+------------+-----------+-------+
1 row in set (0.00 sec)
select * from indexrt where id=3;
+------+------------+-----------+-------+
| id | channel_id | published | title |
+------+------------+-----------+-------+
| 3 | 1 | 1 | bb |
+------+------------+-----------+-------+
1 row in set (0.00 sec)
After the commit statement, the insertions are visible in the table.
By using BEGIN
and COMMIT
, you can define the bounds of a transaction explicitly, so there's no need to worry about autocommit in this case.
begin;
Query OK, 0 rows affected (0.00 sec)
insert into indexrt (id, content, title, channel_id, published) values (2, 'aa', 'bb', 1, 1);
Query OK, 1 row affected (0.00 sec)
select * from indexrt where id=2;
Empty set (0.01 sec)
commit;
Query OK, 0 rows affected (0.01 sec)
select * from indexrt where id=2;
+------+------------+-----------+-------+
| id | channel_id | published | title |
+------+------------+-----------+-------+
| 2 | 1 | 1 | bb |
+------+------------+-----------+-------+
1 row in set (0.01 sec)