diff --git a/README.md b/README.md index 1d34fa8..5f6ebc3 100644 --- a/README.md +++ b/README.md @@ -101,7 +101,7 @@ 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 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 @@ 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.