openfga / java-sdk

OpenFGA SDK for Java - https://central.sonatype.com/artifact/dev.openfga/openfga-sdk
https://openfga.dev
Apache License 2.0
31 stars 9 forks source link

The argument types of write api and delete api are inconsistent. #96

Open xXAvoraXx opened 3 months ago

xXAvoraXx commented 3 months ago

Checklist

Description

I am using an object I created with the ClientTupleKey type for both write operation and delete operation, but I encounter a type error for delete operation.

The method deletes(List) in the type ClientWriteRequest is not applicable for the arguments (List) Java(67108979)

package dev.openfga.sdk.api.client.model;

import java.util.List;

public class ClientWriteRequest {
   private List<ClientTupleKey> writes;
   private List<ClientTupleKeyWithoutCondition> deletes;

   public ClientWriteRequest() {
   }

   public static ClientWriteRequest ofWrites(List<ClientTupleKey> writes) {
      return (new ClientWriteRequest()).writes(writes);
   }

   public ClientWriteRequest writes(List<ClientTupleKey> writes) {
      this.writes = writes;
      return this;
   }

   public List<ClientTupleKey> getWrites() {
      return this.writes;
   }

   public static ClientWriteRequest ofDeletes(List<ClientTupleKeyWithoutCondition> deletes) {
      return (new ClientWriteRequest()).deletes(deletes);
   }

   public ClientWriteRequest deletes(List<ClientTupleKeyWithoutCondition> deletes) {
      this.deletes = deletes;
      return this;
   }

   public List<ClientTupleKeyWithoutCondition> getDeletes() {
      return this.deletes;
   }
}

Expectation

The arguments of the delete api must have the same type as the arguments of the write api.

Reproduction

        ClientWriteRequest client = new ClientWriteRequest();

        List<ClientTupleKey> tuples = new ArrayList<ClientTupleKey>();

        tuples.add(new ClientTupleKey()
                .user("parent_group:" + event.getEventUserId())
                .relation("assignee")
                ._object("group:" + event.getEventUserId()));
        tuples.add(new ClientTupleKey()
                .user("member_group:" + event.getEventUserId())
                .relation("assignee")
                ._object("group:" + event.getEventUserId()));

        if(event.isEventUserChildOfObject()){
            tuples.add(new ClientTupleKey()
                    .user("parent_group:" + event.getEventUserId())
                    .relation("parent")
                    ._object("parent_group:" + event.getEventObjectId()));

            tuples.add(new ClientTupleKey()
                    .user("member_group:" + event.getEventObjectId())
                    .relation("member")
                    ._object("member_group:" + event.getEventUserId()));
        }

        if(event.isWriteOperation()) {
            client.writes(tuples);
        }
        else if(event.isDeleteOperation()) {
            client.deletes(tuples);
        }

OpenFGA SDK version

0.5.0

OpenFGA version

1.5.7

SDK Configuration

-

Logs

No response

References

No response

jimmyjames commented 1 month ago

:wave: hi @xXAvoraXx, thanks for raising an issue!

If I am understanding correctly, you are expecting that the tuple arguments for write and delete are the same. However, the schema for writes vs. delete is actually different, hence the different argument types. The write schema looks like this, notice the different types for the argument to write versus delete (because write accepts a condition param, but delete does not):

image

As the models are generated from the API schema, we see that the SDK type is consistent with the API schema. Hope that helps clear up any confusion!

xXAvoraXx commented 1 month ago

Hi @jimmyjames I actually expect it to accept the same type conversions as in the .NET SDK, because there is no condition in the tuples value I create with ClientTupleKey and I waste time doing type conversions when I want to delete. If you examine the example I gave, I create the tuples with ClientTupleKey when the event is delete or write, but if it is delete, I have to do a type conversion.