REPLACE

REPLACE works similar to INSERT, but it marks the old document with the same ID as a new document as deleted before inserting a new document.

📋
REPLACE INTO products VALUES(1, "document one", 10);
Response
Query OK, 1 row affected (0.00 sec)

REPLACE is supported for RT and PQ indexes.

The old document is not removed from the index, it is only marked as deleted. Because of this the index size grows until index chunks are merged and documents marked as deleted in these chunks are not included in the chunk created as a result of merge. You can force chunk merge by using OPTIMIZE statement.

The syntax of the REPLACE statement is identical to INSERT syntax:

REPLACE INTO index [(column1, column2, ...)]
    VALUES (value1, value2, ...)
    [, (...)]

REPLACE using HTTP protocol is performed via the /replace endpoint. There's also a synonym endpoint, /index.

Multiple documents can be replaced at once. See bulk adding documents for more details.

📋
REPLACE INTO products(id,title,tag) VALUES (1, 'doc one', 10), (2,' doc two', 20);
Response
Query OK, 2 rows affected (0.00 sec)

UPDATE

Attribute updates replace attribute values of existing documents in the specified index with new values. Note that you can't update the contents of a fulltext field. If there's a need to change the contents of a fields, use REPLACE.

Attribute updates are supported for RT, PQ and disk indexes. All attributes types can be updated.

Note that document id attribute cannot be updated.
📋
UPDATE products SET enabled=0 WHERE id=10;
Response
Query OK, 1 row affected (0.00 sec)

Multiple attributes can be updated in a single statement.

📋
UPDATE products
SET price=100000000000,
    coeff=3465.23,
    tags1=(3,6,4),
    tags2=()
WHERE MATCH('phone') AND enabled=1;
Response
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.

📋
insert into products values (1,'title','{"tags":[1,2,3]}');

update products set data.tags[0]=100 where id=1;
Response
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.

📋
insert into products values (1,'title','{"tags":[1,2,3]}');

update products set data='{"tags":["one","two","three"]}' where id=1;
Response
Query OK, 1 row affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)

When using replication, index 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 info.

{
  "cluster":"nodes4",
  "index":"test",
  "id":1,
  "doc":
  {
    "gid" : 100,
    "price" : 1000
  }
}
📋
update weekly:posts set enabled=0 where id=1;

Updates via SQL

Here is the syntax for the SQL UPDATE statement:

UPDATE index SET col1 = newval1 [, ...] WHERE where_condition [OPTION opt_name = opt_value [, ...]]

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.

📋
insert into products values (1,'title','{"tags":[1,2,3]}');

update products set data.tags[0]=100 where id=1;
Response
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 SELECT statement. Specifically for UPDATE statement you can use these options:

  • 'ignore_nonexistent_columns' - If set to 1 points that the update will silently ignore any warnings about trying to update a column which is not exists in current index schema. Default value is 0.
  • 'strict' - this option is used in partial JSON attribute updates. By default (strict=1), UPDATE will end in an error if the UPDATE query tries to perform an update on non-numeric properties. With strict=0 if multiple properties are updated and some are not allowed, the UPDATE will not end in error and will perform the changes only on allowed properties (with the rest being ignored). If none of the SET changes of the UPDATE are not permitted, the command will end in an error even with strict=0.

Updates via HTTP

Updates using HTTP protocol are performed via the /update endpoint. 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.

HTTP
📋
POST /update
{
  "index":"test",
  "id":1,
  "doc":
   {
     "gid" : 100,
     "price" : 1000
    }
}
Response
{
  "_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 in the example above) or you can do an update by query and apply the update to all the documents that match the query:

HTTP
📋
POST /update

{
  "index":"test",
  "doc":
  {
    "price" : 1000
  },
  "query":
  {
    "match": { "*": "apple" }
  }
}
Response
{
  "_index":"products",
  "updated":1
}

Query syntax is the same as in the /search endpoint. Note that you can't specify id and query at the same time.

Flushing attributes

FLUSH ATTRIBUTES

Flushes all in-memory attribute updates in all the active disk indexes to disk. Returns a tag that identifies the result on-disk state (basically, a 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.

Bulk updates

Several update operations can be performed 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 itself should be formatted as a newline-delimited json (NDJSON). Basically it means that each line should contain exactly one json statement and end with a newline \n and maybe a \r.

HTTP
📋
POST /bulk

{ "update" : { "index" : "products", "id" : 1, "doc": { "price" : 10 } } }
{ "update" : { "index" : "products", "id" : 2, "doc": { "price" : 20 } } }
Response
{
   "items":
   [
      {
         "update":
         {
            "_index":"products",
            "_id":1,
            "result":"updated"
         }
      },
      {
         "update":
         {
            "_index":"products",
            "_id":2,
            "result":"updated"
         }
      }
   ],
   "errors":false
}

/bulk endpoint supports inserts, replaces and deletes. Each statement starts with an action type (in this case, update). Here's a list of the supported actions:

  • insert: Inserts a document. Syntax is the same as in the /insert endpoint.
  • create: a synonym for insert
  • replace: Replaces a document. Syntax is the same as in the /replace.
  • index: a synonym for replace
  • update: Updates a document. Syntax is the same as in /update.
  • delete: Deletes a document. Syntax is the same as in /delete endpoint.

Updates by query and deletes by query are also supported.

📋
POST /bulk

{ "update" : { "index" : "products", "doc": { "tag" : 1000 }, "query": { "range": { "price": { "gte": 1000 } } } } }
{ "update" : { "index" : "products", "doc": { "tag" : 0 }, "query": { "range": { "price": { "lt": 1000 } } } } }
Response
Array(
    [items] => Array (
        Array(
            [update] => Array(
                [_index] => products
                [updated] => 0
            ) 
        )   
        Array(
             [update] => Array(
                 [_index] => products
                 [updated] => 3
             ) 
        )    
)

Note that the bulk operation stops at the first query that results in an error.

Settings related with updates

attr_update_reserve

attr_update_reserve=size

attr_update_reserve is a per-index setting which sets the space to be reserved for blob attribute updates. Optional, default value is 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. But if the updated string is longer, updates are written to the end of the .SPB file. This file is memory mapped, that's why 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 by using this option.

📋
create table products(title text, price float) attr_update_reserve = '1M'

attr_flush_period

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.

Deleting documents

Deleting is only supported for Real-Time and percolate indexes and for distributed that contain only RT indexes as agents. You can delete existing rows (documents) from an existing index based on ID or conditions.

Deleting works for SQL and HTTP interfaces.

SQL response for successful operation will show the number of rows deleted.

json/delete is an HTTP endpoint for for deleting. The server will respond with a JSON object stating if the operation was successful or not and the number of rows deleted.

To delete all documents from an index it's recommended to use instead the index truncation as it's a much faste operation.

📋
DELETE FROM index WHERE where_condition
  • index is a name of the index from which the row should be deleted.
  • where_condition for SQL has the same syntax as in the SELECT statement.
Response
{
  "_index": "test",
  "_id": 1,
  "found": true,
  "result": "deleted"
}


{
  "_index": "test",
  "deleted": 4
}

In this example we are deleting all documents that match full-text query dummy from index named test:

📋
select * from test;

delete from test where match ('dummy');

select * from test;
Response
+------+------+-------------+------+
| 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)

Query OK, 2 rows affected (0.00 sec)

+------+------+-------------+------+
| 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)

Here - deleting a document with id 100 from index named test:

📋
delete from test where id=100;

select * from test;
Response
Query OK, 1 rows affected (0.00 sec)

+------+------+-------------+------+
| id   | gid  | mva1        | mva2 |
+------+------+-------------+------+
|  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  |
+------+------+-------------+------+
5 rows in set (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 dummy and have attribute mva1 with a value greater than 206 or mva1 values 100 or 103 from index named test:

SQL
📋
delete from test where match ('dummy') and ( mva1>206 or mva1 in (100, 103) );

select * from test;
Response
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 nodes4's index test:

📋
delete from nodes4:test where id=100;
Response
Array(
    [_index] => test
    [_id] => 100
    [found] => true
    [result] => deleted
)