# Runbook — UPDATE vs REPLACE in Manticore (which one changes what)

Manticore has **two ways to modify an existing row**, and picking the wrong one
silently fails. The rule:

- **`UPDATE`** — changes **attribute** columns in place (numeric like `int`/`bigint`/`float`,
  and `string` attributes). Fast, no reindex. It **cannot** change a full-text
  `text` field. Trying errors:
  `attribute 'title' can not be updated (full-text field)`.
- **`REPLACE`** — rewrites the **entire document** by `id`. It is the **only** way
  to change the content of a full-text field. It works on any column, but it needs
  the **whole row**: any column you leave out is reset to its default
  (numeric → `0`, string → empty).

Talk to searchd with the MySQL client: `mysql -h127.0.0.1 -P9306`.

## Change a numeric/string attribute → UPDATE
```sql
-- works: price is an attribute
UPDATE catalog SET price=120 WHERE id=1;
-- also works in current Manticore: string attributes are updatable
UPDATE catalog SET sku='A1-NEW' WHERE id=1;
```

## Change a full-text field → REPLACE (with the full row)
`UPDATE catalog SET title='blue silk shirt' WHERE id=2;` **fails** — `title` is a
full-text field. Use REPLACE and **list every column** so the attributes survive:
```sql
-- correct: full row, so price/in_stock are preserved
REPLACE INTO catalog(id,title,price,in_stock) VALUES(2,'blue silk shirt',50,8);
```
After this, `MATCH('silk')` returns id 2 and `MATCH('cotton')` no longer does —
REPLACE rewrote the document, it didn't append to it.

## Pitfalls this runbook prevents
- **`UPDATE` on a `text` field** — errors; the new word never becomes searchable.
- **Partial `REPLACE`** — `REPLACE INTO catalog(id,title) VALUES(2,'blue silk shirt')`
  wipes `price` and `in_stock` to `0`. Always include the columns you want to keep.
- **`INSERT` with an existing id** to "overwrite" — errors `duplicate id`.
  REPLACE is the upsert.
- Assuming `UPDATE` can't touch string attributes — it can; only full-text
  **fields** are off-limits to UPDATE.