update README

README.md

@@ -44,6 +44,10 @@ no rights initially by definition and thus must be granted permissions first.
 
 So we create links from *user:appuser1* to *role:product_manager* in the *has_role* table and a link 
 in the *can_select* table from *role:product_manager* to *product:testproduct*.
+```SurrealQL
+relate user:appuser1->has_role->role:product_manager;
+relate role:product_manager->can_select->(select * from product)
+```
 
 With this setup we can define the necessary permission for select in the *product* table like so
 ```
@@ -95,4 +99,15 @@ Signin fails.
 ## Discussion
 This implementation works at this small, prototypical scale but there are certainly ways to improve this design.
 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. For now we will keep it simple though.
+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 
+following SurrealQL query:
+```SurrealQL
+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 would need to be run as a database function or similar triggered
+whenever rows are inserted. Also this potentially creates a link for each pair of records in the products table and role table. This could lead to a explosive growth in entries - maybe control at the table granularity would be enough for some use cases.
+