@Rupa can you DM the exact command you're using to run SpiceDB?

(including the token)

and also the command you used to create the zed context?

No, this is using the docker image. This is part of the schema:

definition a {
    relation rights: a_rights
    relation b: b
        relation c: c
        relation d: d

    permission view = rights->viewer & b->view & c->view & d->view
    permission manage = view & rights->manager
}

definition a_rights {
    relation viewer: user_role#holder
    relation manager: user_role#holder
}

The LookupResources call is done when we ask spicedb for the permission

manage

of a instance of

a

. How can this lead to a timeout, even with a very limited amount of data?

context canceled

means that the connection was terminated or timed out

you say you're not using the testing mode? how are your tests setting up the environment?

I'm working with the Java client for SpiceDB and noticed that

readPermission

is not available with the

PermissionsServiceFutureStub

. It looks like the method is available in the

PermissionsServiceBlockingStub

. I suspect this is because the blocking stub returns an

Iterator

that under the hood makes more calls to the database as needed. Is there any way to read relationships with a non-blocking API?

you mean

readRelationships

?

oh, yes

the initial request for read relationships is "blocking", but because it returns an iterator, it doesn't really block beyond opening the iterator

and the connection if previously closed

this is a limitation of grpc-java

you only get unary calls out of the future stub - if there's a stream on either or both ends (

readPermission

defines a response stream) you can't use the future stub

you need to use the

AsyncStub

if you want an async interface on

readPermissions

but yeah what Joey is saying is what my understanding is as well. java being multithreaded means that the only thing you're blocking is that particular web server thread (assuming we're talking about a web server), and because it's java there's lots of those to go around

my current understanding is that you really only need the async and future versions if you want to make concurrent requests from the same thread without the overhead of wrapping blocking calls in their own futures (or whatever)

Hello, is there any document where I can find the naming conventions and limitations for spiceDB? Does it support non-ASCII chars, repeating

/

, spaces, length limits, etc.? I made a search in this channel but only found few. Would be interested in an exhaustive list if possible. Thank you 🙂

The real source of truth are the protos

You will find most of the relevant regexes in

authzed/api/v1/core.proto

No non-ascii, no spaces, no repeating

/

, 128 bytes on object types and object IDs, and 64 bytes on relation names.

On object types it’s 63 chars for the prefix portion and 64 chars for the type name

Thank you for the swift response Jake. Wish you a nice Sunday!

I am using java library , is there any example - how to paginate , expand and lookup request ?

There is no support yet for pagination in any of the APIs server side. Some of the APIs (lookup, read) support streaming responses. Expand does not, and may not ever, but it’s lookup corollary lookupsubjects will support streaming responses when it ships.

Pagination will likely be implemented as cursors on each streaming response object and a resume request parameter, and not actually support splitting into “pages”

@Jake In case of expand as there is no plan to support stream , for large data set , won't it cause an issue when data is passed over network call.

The problem with streaming expand is figuring out a serialized tree format

What is the use case for streaming expand that’s not covered by lookupsubjects?

My armature understanding was expand (figuring out child nodes) does the opposite of lookup (figuring out parent nodes ) in a directed graph. Did I get it wrong ?