Script Tools
Scripts are the escape hatch for bulk and aggregate work. Use them when the per-record tools are the wrong instrument: computing a score over thousands of records, updating many records in one pass, or loading a set of records from rows you generate. For ordinary work on a handful of records, use the record tools.
A script runs in a sandbox as the authenticated user, with exactly that user's permissions. It cannot see or change anything the user could not, and it needs no API key or token.
Available tools
| Tool | What it does |
|---|---|
anydb_validate_script | Checks that a script parses and passes the sandbox's safety rules without running any of it. |
anydb_simulate_script | Dry-runs a script and reports what it would do, then returns a runToken that authorizes running it for real. |
anydb_run_script | Runs a simulated script for real and returns only what it computes. |
Recommended sequence
- Call
anydb_validate_scriptto catch a syntax error or a blocked construct cheaply. It proves nothing about what the script would do. - Call
anydb_simulate_script. Reads are real and every write is suppressed: record creation, updates, share and comment changes, email, and notifications report their intent instead of happening. Simulation needs the Business or Enterprise plan. - Review the reported effects with the user.
- Call
anydb_run_scriptwith therunTokenfrom the simulation.
A read-only aggregation, such as counting or scoring, is fully answered by the simulation and needs no real run.
A script that branches on the result of a write behaves differently in simulation, because the write did not happen.
Reading many records
Do not fetch a whole large type in one call. Narrow the read with anydb.findRecordsPage({ typeName, condition, limit, cursor }), or read one parent's records with anydb.getChildren(parentid). Page with a limit of a few hundred and pass the returned nextCursor back as cursor. A run is capped at five minutes. For the script APIs themselves, see AnyDB Scripting.