[fix](doc) REVOKE-FROM.md: add prerequisites + drop parser-rejected example (en+zh)#3850
Merged
Merged
Conversation
…xample (en+zh)
The Examples section ran a dozen REVOKE statements against users,
roles, workload group `g1`, compute group `group1`, storage vault
`vault1`, etc. without ever showing a single CREATE / GRANT. On a
fresh cluster every example fails -- the same shape as the earlier
Bucket-1 / ALTER-USER / DROP-DATABASE missing-setup family.
This PR adds a single Setup block at the top of the Examples section
that creates the users / roles / database / workload group the
examples expect, and runs the prerequisite GRANTs so each subsequent
REVOKE has something to remove.
EN: drop the example REVOKE 'role1','role2' FROM ROLE 'test_role'
The page's own Syntax block (line 43) only documents
REVOKE <role_list> FROM <user_identity>
-- it does NOT allow `FROM ROLE <name>` for the role-list form.
4.1.1's parser confirms: the statement is rejected as
'extraneous input ROLE'. The example contradicted the page's
spec and didn't work on the documented version, so it's removed.
(ZH's example 6 is a different statement -- WORKLOAD GROUP FROM
ROLE, which is supported -- and is kept.)
End-to-end verified on a fresh Doris 4.1.1 cluster:
Setup block: OK
All 10 EN REVOKE examples: OK
All 11 ZH REVOKE examples: OK
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
morningman
pushed a commit
that referenced
this pull request
May 30, 2026
…TABASE / DROP-ROLE / data-bucketing (en+zh) (#3846) ## Summary Five pages document a `<verb> <object>` operation but never show the matching `CREATE` / `GRANT` that establishes the object. On a fresh cluster every one of them fails on the very first example. The 4.x branch is fixing this in #3840 (ALTER-USER), #3842 (DROP-DATABASE / DROP-ROLE / data-bucketing), and #3850 (REVOKE-FROM). This PR ports the exact same fixes to **dev/master**, where the bugs are also present — verified against today's master build. ## Changes | Page | Setup added | |---|---| | `ALTER-USER.md` (en+zh) | `CREATE USER jack@'%' IDENTIFIED BY ...` | | `DROP-DATABASE.md` (en+zh) | `CREATE DATABASE db_test;` | | `DROP-ROLE.md` (en+zh) | `CREATE ROLE role1;` | | `data-bucketing.md` (en+zh) | `CREATE DATABASE IF NOT EXISTS demo;` (table examples qualify with `demo.`) | | `REVOKE-FROM.md` (en+zh) | full prereq block (users / roles / db / workload group + GRANTs for every REVOKE target); EN also drops one example whose `REVOKE roles FROM ROLE` syntax contradicts the page's own Syntax block and is parser-rejected by 4.1.1 | ## Verification End-to-end verified on freshly deployed clusters (4.1.1 + today's master build): ``` CREATE USER jack@'%' ... → 4 ALTER USER variants → DROP USER OK CREATE DATABASE db_test → DROP DATABASE db_test OK CREATE ROLE role1 → DROP ROLE role1 OK CREATE DATABASE demo → CREATE TABLE demo.hash_bucket_tbl → DROP OK REVOKE-FROM setup block (CREATE+GRANT chain) → all 10 EN REVOKE OK REVOKE-FROM setup block (with test_role) → all 11 ZH REVOKE OK ``` ## Related 4.x: #3840 · #3842 · #3850 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
morningman
pushed a commit
that referenced
this pull request
May 30, 2026
…roles-FROM-ROLE example (#3851) ## Summary The Examples section on the EN 2.1 and 3.x `REVOKE-FROM` pages contains: ```sql REVOKE 'role1','role2' FROM ROLE 'test_role'; ``` This syntax has **never** been accepted by Doris — confirmed against the source on every release branch (2.1, 3.0, 3.1, 4.0, 4.1). ## Evidence from the Doris source **Grammar** (`fe/fe-core/src/main/antlr4/org/apache/doris/nereids/DorisParser.g4`, identical shape on every branch): ```antlr | GRANT roles+=identifierOrText (COMMA roles+=identifierOrText)* TO userIdentify #grantRole | REVOKE roles+=identifierOrText (COMMA roles+=identifierOrText)* FROM userIdentify #revokeRole ``` Compare to the **privilege** variants (same file, just above), which DO accept `(userIdentify | ROLE identifierOrText)`. The role-list form only has the `userIdentify` branch — there is no `FROM ROLE` for `REVOKE roles`. **Command class** (`fe/fe-core/src/main/java/org/apache/doris/nereids/trees/plans/commands/RevokeRoleCommand.java`, line 37): ```java /** * REVOKE role [, role] FROM user_identity */ public class RevokeRoleCommand ... { public RevokeRoleCommand(UserIdentity userIdentity, List<String> roles) { ... } } ``` Only `UserIdentity` is accepted as the recipient; there is no role-recipient overload. **No legacy parser path:** the older `fe/fe-core/.../analysis/RevokeStmt.java` was removed; Nereids is the only entry point. (Verified with `find fe -name RevokeStmt.java` → empty.) **Page-internal inconsistency:** - The Syntax block on the same page lists `REVOKE <role_list> FROM <user_identity>` — no `FROM ROLE` branch. - The prose above the example reads "Revoke roles from a user", but `test_role` is a role, not a user. So the example is wrong three independent ways and would fail at the parser with `extraneous input 'ROLE'` on any version it was tried against. ## Changes - `versioned_docs/version-2.1/.../REVOKE-FROM.md` — remove the bad example. - `versioned_docs/version-3.x/.../REVOKE-FROM.md` — remove the bad example. ## Left alone - **ZH** (2.1 / 3.x / 4.x / current): the corresponding "example 6" slot is a *different* statement — `REVOKE USAGE_PRIV ON WORKLOAD GROUP 'g1' FROM ROLE 'test_role';` — which IS supported (it's the privilege-FROM-ROLE form). ZH versions stay as-is. - **`ja-source/`**: out of scope for this PR set (the Japanese translation is owned separately). - **4.x EN** and **dev/master EN**: covered in the sibling PRs (4.x: #3850; dev: #3846). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The Examples section ran a dozen
REVOKEstatements against users, roles, workload groupg1, compute groupgroup1, storage vaultvault1, etc. without ever showing a single CREATE / GRANT. On a fresh cluster every example fails — same shape as the earlier Bucket-1 / ALTER-USER / DROP-DATABASE / DROP-ROLE / data-bucketing missing-setup family.Changes
Added at the top of the Examples section: a single Setup block that
jack@'192.%',jack@'%'), roles (role1,role2,my_role, plustest_roleon the ZH side), thedb1database, and workload groupg1;GRANTstatements so each subsequentREVOKEhas something to remove (you can't revoke a privilege that was never granted).Removed (EN only): the example
The page's own Syntax block (line 43) only documents:
That syntax does not allow
FROM ROLE <name>for the role-list form, and 4.1.1's parser rejects the statement asextraneous input 'ROLE'. The example contradicted the page's spec and didn't work on the documented version.The ZH page also has an example with
FROM ROLEat the same position, but it's a different statement (REVOKE USAGE_PRIV ON WORKLOAD GROUP 'g1' FROM ROLE 'test_role') — that one is supported and is kept.Verification
End-to-end on a fresh Doris 4.1.1 cluster:
Related 4.x missing-setup PRs (now closed)
#3821-#3827 (Bucket 1) · #3840 (ALTER-USER) · #3842 (DROP-DATABASE / DROP-ROLE / data-bucketing) · #this (REVOKE-FROM).
Same set has been backported to dev/master in #3846.
🤖 Generated with Claude Code