https://authzed.com logo
Powered by
spicedb
  • s

    Sleipnir

    01/31/2022, 3:44 PM
    So that means the trigger to set zedtoken will also have to do updates on other tables, which will trigger their zedtoken triggers, so there will have to be careful checks to avoid infinite trigger recursion.
  • j

    Joey

    01/31/2022, 3:45 PM
    not unless those tables are the resource of the relationship
  • j

    Joey

    01/31/2022, 3:45 PM
    if they are the subject, then no need to update a zedtoken
  • j

    Joey

    01/31/2022, 3:46 PM
    in your example, you're updating the investment for a deal resource (I believe)
  • j

    Joey

    01/31/2022, 3:46 PM
    so that means the resource is the 
    deal
    , so only its zedtoken needs to be updated
  • s

    Sleipnir

    01/31/2022, 3:50 PM
    Ahhhh ok. I've been updating the zedtoken on the table being updated, but this has to consider the actual 
    .zed
    schema and update the table that represents the resource.
  • j

    Joey

    01/31/2022, 3:51 PM
    the general rule of thumb is: if it is the resource, update it. if it isn't, no need to do so
  • j

    Joey

    01/31/2022, 3:52 PM
    so if you're writing 
    sometype:objid#relation@anothertype:objid
    , then its for 
    sometype
    that you're storing the updated zedtoken
  • j

    Joey

    01/31/2022, 3:52 PM
    since it has the relation-ship
  • s

    Sleipnir

    01/31/2022, 3:53 PM
    Right. The tricky part is that arrow can be (but isn't always) inverted from the FK->PK relationship.
  • s

    Sleipnir

    01/31/2022, 3:53 PM
    Well that and the zedfile relationship can represent multiple FK hops, in either direction
  • j

    Joey

    01/31/2022, 3:54 PM
    yep
  • j

    Joey

    01/31/2022, 3:55 PM
    although you (usually) don't need to update the zedtoken for the right side of arrow rels, unless you want to be absolutely certain of the consistency on them as well
  • j

    Joey

    01/31/2022, 3:55 PM
    like, if you were to add, say, the parent folder of a document, you'd just make all the write calls in a single API call, then use that zedtoken for the document
  • j

    Joey

    01/31/2022, 3:56 PM
    that way, it reflects all the changes in that write
  • d

    DefinitelyNotSam

    01/31/2022, 4:45 PM
    Is there a way to write a permission that follows this kind of logic 
    definition object {
  relation org: org1
  relation group: group1

  permission view = org->admin if group is null else group->member
}
    pardon my python pseudo-code for the permission
  • j

    Joey

    01/31/2022, 4:46 PM
    @User so admin only if there is no group?
  • d

    DefinitelyNotSam

    01/31/2022, 4:46 PM
    exactly
  • j

    Jake

    01/31/2022, 4:46 PM
    does the group have a relationship to the org?
  • d

    DefinitelyNotSam

    01/31/2022, 4:46 PM
    yes
  • j

    Jake

    01/31/2022, 4:47 PM
    ok then this will work
  • j

    Jake

    01/31/2022, 4:47 PM
    definition object {
  relation org: org1
  relation group: group1

  permission view = (org->admin - group->org_admin) + group->member
}
  • d

    DefinitelyNotSam

    01/31/2022, 4:47 PM
    that's cool
  • j

    Jake

    01/31/2022, 4:48 PM
    org_admin
    here is a synthetic nested arrow on the group because you can't do 
    group->org->admin
  • d

    DefinitelyNotSam

    01/31/2022, 4:49 PM
    so then does org_admin need an explicit definition in the schema somewhere?
  • j

    Joey

    01/31/2022, 4:49 PM
    on the group
  • j

    Joey

    01/31/2022, 4:49 PM
    definition group1 {
  relation org: org1
  permission org_admin = org->admin
}
  • d

    DefinitelyNotSam

    01/31/2022, 4:50 PM
    Oh, very cool
  • d

    DefinitelyNotSam

    01/31/2022, 4:51 PM
    That works very well actually because the edit permission of the group is basically org_admin
  • j

    Joey

    01/31/2022, 4:52 PM
    so yeah, you could do 
    group->edit
    then
1...757677...325Latest