update README

README.md

@@ -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.