Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: change TypeDefinition signature to be more canonical #77

Open
jon-whit opened this issue May 9, 2023 · 1 comment
Open

refactor: change TypeDefinition signature to be more canonical #77

jon-whit opened this issue May 9, 2023 · 1 comment
Labels
breaking-change Will result in a breaking change to the API enhancement New feature or request

Comments

@jon-whit
Copy link
Contributor

jon-whit commented May 9, 2023

Today a TypeDefinition has the following protobuf definition:

message TypeDefinition {
    string type = 1;
    map<string, Userset> relations = 2;
    Metadata metadata = 3;
}

https://github.com/openfga/api/blob/main/openfga/v1/authzmodel.proto#L26

A more canonical and easier consume definition of a TypeDefinition would look like:

message TypeDefinition {
    string type = 1;
    map<string, Relation> relations = 2;
}

https://github.com/openfga/api/blob/main/openfga/v1/authzmodel.proto#L42

The only reason(s) why the metadata field is needed today is because we did not want to break existing compatibility with the Userset definition in the map<string, Userset> and so we introduced an additional field. The Relation definition itself should encapsulate all of the information/metadata associated with the relation. Doing so will allow the OpenFGA core and other integrations to more seemlessly make use of a TypeDefinition and the relations contained therein without having to reconstruct a map[string]Relation all over the place in client code.

References:
https://github.com/openfga/openfga/pull/726/files#r1189164147

@miparnisari
Copy link
Member

Note that this will be a breaking change for the WriteAuthorizationModel API

@rhamzeh rhamzeh added the breaking-change Will result in a breaking change to the API label May 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Will result in a breaking change to the API enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants