palashc commented on code in PR #13:
URL: https://github.com/apache/phoenix-site/pull/13#discussion_r3163941409
##########
app/pages/_docs/docs/_mdx/(multi-page)/features/atomic-upsert.mdx:
##########
@@ -48,6 +48,59 @@ ON DUPLICATE KEY UPDATE
ELSE 'VP APPROVAL' END;
```
+## ON DUPLICATE KEY UPDATE_ONLY [#atomic-upsert-update-only]
+
+`UPDATE_ONLY` is a third variant of the `ON DUPLICATE KEY` clause, available
from
+Phoenix 5.3.0
([PHOENIX-7648](https://issues.apache.org/jira/browse/PHOENIX-7648)).
+Unlike `UPDATE`, the `VALUES` are **not** inserted when the row is missing —
the
+statement is a no-op in that case. Use it when an `UPSERT` should behave
purely as a
+conditional in-place update.
+
+```sql
+UPSERT INTO inventory(id, qty) VALUES ('sku-42', 0)
+ON DUPLICATE KEY UPDATE_ONLY qty = qty - 1;
+```
+
+If `id = 'sku-42'` already exists, its `qty` is decremented under the row lock.
+If it doesn't, the supplied `VALUES` are discarded and nothing is written.
+
+The three forms compared:
+
+| Clause | Row missing | Row
present |
+| ---------------------------------- | -------------------------- |
-------------- |
+| `ON DUPLICATE KEY IGNORE` | Insert from `VALUES` | No-op
|
+| `ON DUPLICATE KEY UPDATE ...` | Insert from `VALUES` | Run the
update |
+| `ON DUPLICATE KEY UPDATE_ONLY ...` | No-op (`VALUES` discarded) | Run the
update |
+
+## Returning the affected row [#atomic-upsert-returning]
+
+A single-row `UPSERT` or `DELETE` can append `RETURNING *` to return the
affected row
+as a JDBC `ResultSet` in the same round-trip, available from Phoenix 5.3.0
+([PHOENIX-7651](https://issues.apache.org/jira/browse/PHOENIX-7651)). The
returned
+row reflects the **server-side state after the mutation** — including any
values
+computed by an `ON DUPLICATE KEY UPDATE` clause under the row lock.
+
+This collapses two common patterns into one round-trip:
+
+- **Atomic read-modify-write counters** — increment, then read the new value
+ without a follow-up `SELECT` (and without risking a different writer
slipping in
+ between).
+- **Tombstoning / queue consumers** — atomically delete a row and read the
payload
+ you just removed, useful for idempotent replay and "claim the next task"
patterns.
+
+```sql
+-- Atomic increment that also returns the post-update row.
+UPSERT INTO counters(id, hits) VALUES ('home', 0)
+ON DUPLICATE KEY UPDATE hits = hits + 1
+RETURNING *;
+
+-- Atomic delete returning the row that was removed.
+DELETE FROM tasks WHERE id = ? RETURNING *;
+```
+
+The statement must affect a single row when `RETURNING *` is used. Drivers
iterate
+the returned `ResultSet` exactly like the result of a regular `SELECT`.
Review Comment:
added
##########
app/pages/_docs/docs/_mdx/(multi-page)/features/view-ttl.mdx:
##########
@@ -0,0 +1,102 @@
+---
+title: "View TTL"
+description: "Per-view retention on top of a shared base table — different
views can age data out on different schedules without splitting the table."
+---
+
+A Phoenix [view](/docs/features/views) is a logical table that shares a single
physical
+HBase table with its sibling views. **View TTL** lets each view define its
**own** data
+retention policy on top of that shared table. Rows that have outlived their
view's TTL
+disappear from queries against that view and are eventually removed in the
background —
+without affecting any other view (or the base table). Available in Phoenix
5.3.0
+([PHOENIX-6978](https://issues.apache.org/jira/browse/PHOENIX-6978)).
+
+## When to use it [#view-ttl-when]
+
+The classic case is **multi-tenant retention**: one shared base table, many
tenant
+views, each tenant gets a different retention window driven by its plan,
region, or
+contract.
+
+| Scenario | View TTL
fit |
+| ---------------------------------------------------------------- |
----------------------------------------------------- |
+| Per-tenant retention windows on one shared base table | Yes
|
+| Per-use-case retention (e.g., "raw events 7 days, audit 1 year") | Yes
|
+| Same retention for the entire physical table | Use a
regular table-level `TTL` instead |
+| Retention based on row content rather than age | Use
[Conditional TTL](/docs/features/conditional-ttl) |
+| Different schemas per tenant | Use
separate tables, not views |
Review Comment:
changed
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
