Improve raw http and transaction explanation

Correct Raw HTTP examples and explain transactions

Author: raphael-istari

docusaurus-docs/docs/clients/raw-http.md

@@ -50,7 +50,8 @@ In DQL, you add data using a set mutation, identified by the `set` keyword.
 ```
 </TabItem>
 <TabItem value="rdf" label="RDF">
-```
+triples are in [RDF](dql-rdf) format.
+```sh
 {
   set {
     # triples in here
@@ -62,8 +63,8 @@ In DQL, you add data using a set mutation, identified by the `set` keyword.
   }
 }
 ```
-
-triples are in [RDF](dql-rdf) format.
+</TabItem>
+</Tabs>
 
 ###  Node reference
 A mutation can include a blank nodes as an identifier for the subject or object, or a known UID.
@@ -87,8 +88,7 @@ will add the `release_date` information to the node identified by UID `0x632ea2`
 }
 ```
 
-</TabItem>
-</Tabs>
+
 
 
 ## delete block
@@ -127,14 +127,9 @@ indexing) is removed with the pattern `S P *`.
 }
 ```
 
-The pattern `S * *` deletes all the known edges out of a node, any reverse edges
+The pattern `S * *` deletes all predicates from a node `S`, along with any reverse edges
 corresponding to the removed edges, and any indexing for the removed data.
 
-:::note For mutations that fit the `S * *` pattern, only
-predicates that are among the types associated with a given node (using
-`dgraph.type`) are deleted. Any predicates that don't match one of the
-node's types will remain after an `S * *` delete mutation.:::
-
 ```sh
 {
   delete {
@@ -143,13 +138,29 @@ node's types will remain after an `S * *` delete mutation.:::
 }
 ```
 
-If the node `S` in the delete pattern `S * *` has only a few predicates with a
-type defined by `dgraph.type`, then only those triples with typed predicates are
-deleted. A node that contains untyped predicates will still exist after a
-`S * *` delete mutation.
+:::note
+When using the `S * *` pattern, Dgraph only deletes predicates that are defined in the types associated with the node via `dgraph.type`. 
+
+For example, if a node has `dgraph.type: ["Person", "Author"]`, and the `Person` type defines predicates `name`, `age`, and `email`, while the `Author` type defines predicates `name` and `author.of`, then `S * *` will only delete triples for predicates that appear in at least one of these types (`name`, `age`, `email`, `author.of`).
+
+Any predicates on the node that are not defined in any of the node's types will remain after the `S * *` delete mutation. This means:
+- If a node has untyped predicates (predicates not in any `dgraph.type`), those predicates will not be deleted.
+- If a node has no `dgraph.type` assigned, `S * *` will have no effect.
+:::
+
+**Example:**
+
+Consider a node with UID `0x123` that has:
+- `dgraph.type: "Person"` (where `Person` type defines `name`, `age`, `email`)
+- Predicate `name: "Alice"` (typed - will be deleted)
+- Predicate `age: "30"` (typed - will be deleted)  
+- Predicate `custom_field: "value"` (untyped - will NOT be deleted)
+
+After executing `delete { <0x123> * * . }`, the node will still exist with only `custom_field: "value"` remaining.
 
-:::note The patterns `* P O` and `* * O` are not supported because
-it's inefficient to store and find all the incoming edges. :::
+:::note
+The patterns `* P O` and `* * O` are not supported.
+:::
 
 ### Deletion of non-list predicates
 

docusaurus-docs/docs/dql/dql-mutation.md

@@ -21,7 +21,35 @@ Dgraph stores data as facts using predicates. Each fact follows the pattern: `<n
 
 For detailed definitions, see the [Dgraph Glossary](/dgraph-glossary) and [design concepts](/design-concepts/relationships-concept).
 
----
+## Transactions
+
+Dgraph supports transactions to ensure data consistency and atomicity. A transaction groups multiple operations (queries and mutations) into a single atomic unit.
+
+### Transaction Lifecycle
+
+1. **Start a transaction**: When you execute a query or mutation, Dgraph automatically starts a new transaction and assigns it a unique transaction ID (also called `start_ts` or start timestamp).
+
+2. **Execute operations**: Within a transaction, you can perform multiple queries and mutations. All operations in the same transaction use the same transaction ID to ensure they see a consistent view of the data.
+
+3. **Commit or rollback**: 
+   - **Commit**: Makes all changes in the transaction permanent. After committing, the changes are visible to other transactions.
+   - **Rollback (abort)**: Discards all changes in the transaction. The database returns to its state before the transaction started.
+
+### Transaction Contents
+
+A transaction can contain:
+- **Queries**: Read data from the database
+- **Mutations**: Add, modify, or delete data
+
+You can perform multiple queries and mutations within a single transaction before committing. This allows you to read data, make decisions based on that data, and then apply mutations—all while maintaining consistency.
+
+### Read-Only Transactions
+
+Read-only transactions are optimized for read operations and cannot contain mutations. They are useful to increase read speed because they can circumvent the usual consensus protocol. Attempting to perform a mutation in a read-only transaction will result in an error.
+
+Read-only queries can optionally be set as **best-effort**. Using this flag asks the Dgraph Alpha to try to get timestamps from memory on a best-effort basis to reduce the number of outbound requests to Zero. This may yield improved latencies in read-bound workloads where linearizable reads are not strictly needed.
+
+For more details, see [Transactions](../design-concepts/transactions-concept) and [DQL Query](query/dql-query).
 
 
 

docusaurus-docs/docs/dql/index.md

@@ -23,6 +23,19 @@ A DQL query has
 
 ![DQL Query with parameterization](/images/dql-syntax/query-syntax-1.png)
 
+### Read-Only Transactions
+
+Read-only transactions can be created by calling `c.NewReadOnlyTxn()`. Read-only
+transactions are useful to increase read speed because they can circumvent the
+usual consensus protocol. Read-only transactions cannot contain mutations and
+trying to call `txn.Commit()` will result in an error. Calling `txn.Discard()`
+will be a no-op.
+
+Read-only queries can optionally be set as best-effort. Using this flag will ask
+the Dgraph Alpha to try to get timestamps from memory on a best-effort basis to
+reduce the number of outbound requests to Zero. This may yield improved
+latencies in read-bound workloads where linearizable reads are not strictly
+needed.
 
 ### Query parameterization
 **Parameters**