Does DEFINE TABLE OVERWRITE reset permissions in SurrealDB?

DEFINE TABLE OVERWRITE without PERMISSIONS

Warning: the statement succeeds, then writes fail, access changes, or the table is held up.

What happens

Observed on SurrealDB 3.0.2: a table defined with PERMISSIONS FOR select WHERE published = true reads back as PERMISSIONS NONE in INFO FOR DB after DEFINE TABLE OVERWRITE post SCHEMALESS.

Why it is dangerous on a populated table

Table size does not change this one: from the moment the statement runs, every record user sees and writes nothing in the table, however many records it holds, until the permissions are restated.

Fires on

DEFINE TABLE OVERWRITE post SCHEMALESS;

The safe pattern

DEFINE TABLE OVERWRITE post SCHEMALESS PERMISSIONS FOR select WHERE published = true FOR create, update, delete WHERE author = $auth.id;

Fixtures

The rule ships with these files and the test suite runs them on every change: the first set must fire, the second must stay silent.

DEFINE TABLE OVERWRITE post CHANGEFEED 7d;

DEFINE TABLE OVERWRITE post SCHEMALESS;

ALTER TABLE post CHANGEFEED 7d;

DEFINE TABLE OVERWRITE post SCHEMALESS PERMISSIONS FOR select WHERE published = true FOR create, update, delete WHERE author = $auth.id;

How to check locally

npx bolvrk check migration.surql --engine=surrealdb