[PR] Support parsing Oracle CREATE TABLESPACE with encryption clause without algorithm [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

terrymanu opened a new pull request, #39556:
URL: https://github.com/apache/shardingsphere/pull/39556

   Oracle tablespace encryption clause allows ENCRYPTION without an explicit USING algorithm, e.g. CREATE TABLESPACE securespace DATAFILE ... SIZE 100M ENCRYPTION DEFAULT STORAGE (ENCRYPT). Make tablespaceEncryptionSpec optional in permanentTablespaceClause, consistent with alterTablespace clauses, and add parser IT cases from the issue examples.
   
   Fixes #27116
   


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Support parsing Oracle CREATE TABLESPACE with encryption clause without algorithm [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

terrymanu commented on PR #39556:
URL: https://github.com/apache/shardingsphere/pull/39556#issuecomment-5380036204

   ### Result
   
   **Review Result: Mergeable**
   
   PR #39556 (head `069c8544f8a`, base master `b3cdad82cb2`) closes the last unparsable form among the five examples of issue #27116: `ENCRYPTION` without a `USING` algorithm clause. The change is a pure widening of the accepted grammar (one optional token plus two test cases), supported by official documentation, an in-repository precedent, and a full local Oracle parser IT run. No blocking issue was found.
   
   ### Evidence
   
   - Syntax correctness (official docs): the Oracle 19c SQL Language Reference chapter "CREATE TABLESPACE" states for the encryption clause semantics "If you omit this clause, then the database uses AES128", i.e. `USING 'encrypt_algorithm'` is optional (https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CREATE-TABLESPACE.html). Example 1 of issue #27116 (securespace) is exactly this bare `ENCRYPTION` form.
   - Change under review: `parser/sql/engine/dialect/oracle/src/main/antlr4/imports/oracle/DDLStatement.g4:4216` changes `ENCRYPTION tablespaceEncryptionSpec` to `ENCRYPTION tablespaceEncryptionSpec?`. The optionality is added only at the CREATE usage site, consistent with the existing optional form in the `alterTablespace` encryption clauses (`DDLStatement.g4:4279-4280`); the rule body `tablespaceEncryptionSpec : USING encryptAlgorithmName` is untouched, so the `USING` form behaves unchanged (existing case `create_tablespace_with_encrypt` passes as regression).
   - Root cause and completeness: #39545 (already in base) fixed the DATAFILE position and the repeatable options group `)*`; after this PR all five issue examples parse into `CreateTablespaceContext` (including the `ALTER TABLESPACE ... ADD DATAFILE` statement of example 3), while the legacy non-standard ordering removed by #39545 is still rejected — no compatibility regression.
   - Test validity: `test/it/parser/src/main/resources/sql/supported/ddl/create-tablespace.xml:46` (issue example 4: DATAFILE + EXTENT MANAGEMENT LOCAL + SEGMENT SPACE MANAGEMENT AUTO + ONLINE, protecting the `)*` multi-option repetition path) and `:59` (issue example 1 verbatim: bare ENCRYPTION + DEFAULT STORAGE (ENCRYPT), protecting the new branch). The case XML entries (`case/ddl/create-tablespace.xml:37,50`) keep `sql-case-id` aligned, with the same empty-assert form as the existing `CreateTablespaceStatement` contract.
   - Local verification (sanitized summaries, all exit 0): `./mvnw -pl test/it/parser -Dtest=InternalOracleParserIT test` → Tests run: 1889, Failures: 0, Errors: 0 (including the 2 new cases; an initial run had 67 errors caused by a locally stale SNAPSHOT missing the Doris class from #39552, resolved by refreshing that unrelated module — not PR-related); `./mvnw checkstyle:check -Pcheck -pl parser/sql/engine/dialect/oracle,test/it/parser` passed; `spotless:apply` produced no additional diff; ANTLR generation emitted no warnings.
   - Dialect boundary: Oracle is a trunk dialect with no branch dialects (CODE_OF_CONDUCT.md dialect table); the changed file lives in Oracle-only imports, so MySQL/Doris/openGauss CREATE TABLESPACE grammars are unaffected. Visitor, statement model, SPI, and public APIs are unchanged.
   
   ### Coverage
   
   - Reviewed scope: head `069c8544f8a` (local HEAD equals the public head, merge-base `b3cdad82cb2`, clean worktree); the authoritative GitHub file list of 3 files matches the local triple-dot list exactly (grammar 1+/1-, SQL cases 2+/0-, expected cases 2+/0-).
   - Requirements basis: the five examples of issue #27116 (compared one by one) plus the PR description (Fixes #27116); the PR has no prior reviews or comments to reconcile.
   - Behavior clusters: 1 (`oracle-create-tablespace-encryption-optionality`); all 3 files mapped, no churn-only files.
   - Discovery lenses: root-cause/behavior, blast-radius/contracts, and tests/runtime/operations lenses completed; the full-scope convergence pass produced 0 new independent candidates; the Finding Proof Gate confirmed no blocking issue (the considered "example-4 case does not protect the new branch" was classified as a non-blocking observation and is not published).
   - Unresolved gaps: none.
   - CI scope: this result is code-scope only (Code Correctness Review); CI/Actions were not queried or reviewed.


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Support parsing Oracle CREATE TABLESPACE with encryption clause without algorithm [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

terrymanu merged PR #39556:
URL: https://github.com/apache/shardingsphere/pull/39556


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org