The following queries show an example of how to remove resources.
REMOVENAMESPACEsurrealdb;
REMOVEDATABASEblog;
REMOVEUSERwriterONNAMESPACE;
REMOVEUSERwriterONDATABASE;
REMOVEACCESS token ONNAMESPACE;
REMOVEACCESS user ONDATABASE;
REMOVEEVENTnew_postONTABLEarticle;
-- Only works for Schemafull tables (i.e. tables with a schema) REMOVEFIELDtagsONTABLEarticle;
REMOVEINDEXauthorsONTABLEarticle;
REMOVEANALYZERexample_ascii;
REMOVEFUNCTIONfn::update_author;
REMOVEPARAM$author;
REMOVETABLEarticle;
Using if exists clause
The following queries show an example of how to remove resources using the IF EXISTS clause, which will only remove the resource if it exists.
REMOVENAMESPACEIFEXISTSsurrealdb;
REMOVEDATABASEIFEXISTSblog;
REMOVEUSERIFEXISTSwriterONNAMESPACE;
REMOVEUSERIFEXISTSwriterONDATABASE;
REMOVE ACCESS IFEXISTStoken ON NAMESPACE;
REMOVE ACCESS IF EXISTS user ONDATABASE;
REMOVEEVENTIFEXISTSnew_postONTABLEarticle;
REMOVEFIELDIFEXISTStagsONTABLEarticle;
REMOVEINDEXIFEXISTSauthorsONTABLEarticle;
REMOVEANALYZERIFEXISTSexample_ascii;
REMOVEFUNCTIONIFEXISTSfn::update_author;
REMOVEPARAMIFEXISTS$author;
REMOVETABLEIFEXISTSarticle;
Usage in table views
A table used as a source for a table view cannot be removed until the table view itself has been removed.
DEFINETABLEpc; DEFINETABLEpc_aggASSELECTcount(), classFROMpcGROUPBYclass; CREATE |pc:3| SETclass="Wizard"; CREATE |pc:10| SETclass="Warrior"; SELECT * FROMpc_agg; -- Error: pc_agg requires pc to work REMOVETABLEpc; REMOVETABLEpc_agg; -- pc_agg is now gone, pc can be removed too REMOVETABLEpc;
The SELECT * FROM pc_agg query shows that the table view is pulling data from the pc table. As long as the pc table exists, pc_agg cannot be removed.
'Invalid query: Cannot delete table `pc` on which a view is defined, table(s) `pc_agg` are defined as a view on this table.'
Behaviour after removal
While all REMOVE statements remove the definition for a resource, some resources have additional actions when removed. They are:
REMOVE DATABASE: This effectively deletes the database by removing the index stores, deleting the definition, and clearing the cache.
REMOVE NAMESPACE: Same as REMOVE DATABASE, in addition to performing a remove on each database inside the namespace.
REMOVE TABLE: Similar to the two previous statements but on a single table, and will fail if a table view depends on it. Removing a table will also send a KILL notification for each live query defined on it.
REMOVE INDEX: This statement also removes the index store cache and index data. If you are considering removing an index but want to test the behaviour out first, use an ALTER INDEX PREPARE REMOVE statement. This will decommission the index, after which you can test out queries to see their behaviour as they would function after the index is removed. If acceptable then the index can then be removed, or the change can be reverted by rebuilding the index.
Another REMOVE statement to note is REMOVE FIELD, as it does not remove any existing data. To remove the existing data, perform an UPDATE or UPSERT statement that uses UNSET on the field or sets the field's value to NONE.
For a schemaless table, the existing data will remain present until unset.
SELECT * FROMperson; -- 'name' data is still there UPDATEperson; -- Does nothing -- [{ id: person:one, name: 'Billy' }] UPDATEpersonSETname=NONE; -- Must unset to remove 'name' data
For a schemafull table, read operations can be performed on a table that still contains data not defined in the schema. However, any updates will fail unless the field is unset to match the schema.
SELECT * FROMperson; -- 'name' data is still there UPDATEperson; -- Found field 'name', but no such field exists for table 'person' DEFINEFIELDcreated_atONpersonTYPEdatetime; -- Define a new field
-- Works because values matche schema: 'name' is set to NONE, 'created_at' has a datetime value UPDATEpersonSETname=NONE, created_at=time::now();