Is there a way, or has there been any thought about specifying an expiration time for a relationship at

Create

time?

@cjs There is currently no way. We have talked about it, and more broad support for conditional relationships but nothing concrete has come of it yet

Hello 👋 I have a question about resource deletion using the gRPC api. Currently I use the method

WriteRelationships

to create my users with something like that :

message WriteRelationships {
   // Check that the user is not already linked to another project
   optionalPreconditions: [{
     optional_preconditions: MUST_NOT_MATCH
     filter: {
        resource_type: 'user'
        optional_resource_id: 'user_id'
        optional_subject_filter: {
           subject_type: 'project'
        }
     }
   }],

   updates: [{
      operation: 'CREATE'
      relationship: {
         subject: {
            object: {
              object_type: 'project'
              object_id: 'project_id'
            }
         }
         reference: {
            object_type: 'user',
            object_id: 'user_id'
         }
      }
   }]
}

Until then everything works as expected, however if I delete the relation calling

DeleteRelationships

:

message DeleteRelationshipsRequest {
   relationship_filter: {
      resource_type: 'user'
      optional_resource_id: 'user_id'
   }
}

I'm not able to re-call the same WriteRelationships request as the precondition fails. Is it a normal behaviour ? Is there something I missing during the deletion ?

@User it sounds like a bug. What datastore backend are you using? Can you try changing the CREATE to a TOUCH?

Hey friends 👋🏻 Been thinking about how spicedb could support the safe rollout of schema changes, wanted to hear your thoughts. In an ideal world, we can support our engineering team to follow the same patterns we do today, such as progressive rollouts, and being able to rollback product changes, with a focus on minimizing customer impact. Have y'all considered how this can be achieved? Some of the options that come to mind: - **Schema versioning**: a client can "Write" a new version of the schema. Clients need to indicate the version to use when they talk to SpiceDB. SpiceDB is capable of marking all state kept on run-time in association with a specific Schema version (e.g. caches for version 1 are not considered for version 2). Client's can eventually cut-over to a specific version. - **Blue/Green SpiceDB deployments**: a new deployment of SpiceDB is provisioned, configured with the same database, but configured to use a different version of the schema. Clients switch between versions using the corresponding DNS.

The challenge with the system as it stands today is that performing the Write Schema RPC would immediately change the semantics of our authorization system to 100% of users. Think changing a

permission

. We want to control to which of our customer requests is the new functionality exposed.

@User I've actually just put in a change to tie relationships more closely to their schema: https://github.com/authzed/spicedb/pull/332

ooooh how timely, that would unlock the scenarios described above! 👏

only sort of

this actually makes it harder to use a different namespace than the one that was in effect at the time you committed

it's sort of contentious the idea of letting you re-interpret a set of relationships with a different schema

because we can't, for example, know for sure that all of the restrictions on types in the schema were in place when the relationships were written

however, we have also discussed the ability to send along either schema as of revision parameter or the schemas themselves on the redispatch API to allow for testing new schemas and other such scenarios

theoretically we could make sure that schemas are compatible with tooling

the idea of being able to specify the schema revision as a request header is an interesting one

we could check that the schema revision you're requesting is compatible with the one currently gating server mutations and potentially reject the request if not

i don't think the blue/green proposal is feasible today because the schemas are stored and revision controlled in the datastore right alongside the relationships

right, I think I take for granted that there has to always be compatibility between schema revision.

e.g. a new revision adds new relations and changes permissions

then if you wrote a relationship indicating the schema revision, it would be allowed if it conformed to the new schema, and the execution of requests with the old schema wouldn't in theory change semantics

however I wonder if there are scenarios where a writing new relationships according to a new schema could lead to a different interpretation according to the old schema

also worth acknowledging that you can certainly perform mutations via schema v2 and have side effects in v1, but that it would be in accordance to the semantics expected in v1

I guess in a world where the concept of schema revision and client-provided schema revision exist we don't really need blue/green

we do in fact the same in our authorization service

> however I wonder if there are scenarios where a writing new relationships according to a new schema could lead to a different interpretation according to the old schema completely new relations, probably not. However, if the type of a relation was changed (say, to add support for another relation on the right hand side), and a relationship written to that, it definitely could

oooh I see yeah

like

relation owner: user

. ->

relation owner: user | organization

would break v1

I guess that would be addressed if tuples had also a schema revision associated?

yep, in one way or another, either by "missing" organizations because they aren't in the type graph, or by finding organization relationships and not handling them properly

I imagine reading tuples like the snapshot isolation mechanism y'all implemented with zedtokens and MVCC