|
|
@@ -101,7 +101,7 @@ This implementation works at this small, prototypical scale but there are certai
|
|
|
In SurrealDB relation tables can have fields. Maybe the relation tables *can_select*, *can_create* etc. should
|
|
|
be collapsed into a single table *rights* having a field of type set<string> with the optional values "select", "create", "update", "delete". This might be easier to maintain than four different relation tables.
|
|
|
|
|
|
-When creating our relation entries in the *can_select* relation table we use the
|
|
|
+When creating our relation entries in the *can_select* table we use the
|
|
|
following SurrealQL query:
|
|
|
```SurrealQL
|
|
|
relate role:product_manager->can_select->(select * from product)
|
|
|
@@ -109,5 +109,5 @@ relate role:product_manager->can_select->(select * from product)
|
|
|
This gives us row level access control which is nice. For example we could
|
|
|
restrict select access to *yellow* products for product_managers.
|
|
|
|
|
|
-However there are two things two keep in mind. This query would need to be run as a database function or similar triggered whenever rows are inserted. This approach potentially creates a link for each pair of records in the *product* and *role* tables. Also one should make sure that these entries are unique. This could lead to a quick growth in entries - maybe access control with table granularity would be enough for some use cases.
|
|
|
+However there are two things two keep in mind. This query would need to be run as a database function or something similar triggered whenever rows are inserted. The [```DEFINE EVENT```](https://surrealdb.com/docs/surrealql/statements/define/event) could fit the bill. This approach potentially creates a link for each pair of records from the *role* and *product* tables. This could lead to a quick growth in entries - maybe access control with table granularity would be enough for some use cases. Additionally one should make sure via database constraints that these link entries are unique.
|
|
|
|
david