Repository navigation
Build with VoidQL
gaiacasalinuovo-hub edited this page Aug 20, 2026
·
1 revision
This page is the guided implementation map. Exact types are in DSL Reference.
Each key maps a public table name to its Drizzle table object and endpoint definitions.
const structure = {
projects: {
table: projects,
endpoints: [
{ type: "GET", admin: ALL, member: { allowed: ["id", "name"], disallowed: [] } },
{ type: "PUT", admin: ALL, member: NONE }
]
}
};Every operation needs its own endpoint. A role that is absent is rejected. ALL, ALL_EXCEPT_ID, and NONE are built-in permission presets.
Use allowed and disallowed (or their aliases allow and deny) to form the effective field set. "*" represents every mapped field.
Use an object-shaped field permission with field and where:
member: {
allowed: {
field: ["id", "name", "owner_id"],
where: { field: "owner_id", operator: "=", value: "$user.id" }
},
disallowed: []
}const request = {
table: "projects",
type: "GET",
select: ["projects.id", "projects.name"],
order_by: "projects.name ASC",
limit: 25
};const plan = await compile(db, request, currentUser, currentRole, structure);
const result = await plan.execute();Compilation can reject invalid tables, fields, endpoints, roles, or policy shapes. Execution returns the result envelope described in Errors and Results.
- Define an endpoint for every intended operation.
- Give every supported role an explicit permission object or preset.
- Prefer qualified field names in joins and complex conditions.
- Treat
$uservalues as trusted only if the application constructed the session securely. - Test both allowed and denied paths.
- Route all protected access through VoidQL if VoidQL is your enforcement boundary.
VoidQL is experimental and under active development · Documentation home · Status & limitations
Start Here
Learn & Build
- Learn VoidQL
- Build with VoidQL
- Query Operations
- Authorization Patterns
- Validation & Workflows
- Triggers & Extensibility
Use & Reference
Internals & Project