@User can you share the commands you're running? I just wrote the same schema twice with

zed

without any errors (using the latest

zed

and

spicedb

from homebrew)

And what datastore are you using for spicedb?

Oh my bad, this was due to a bad schema 🤦‍♂️ In my schema file I declared twice the same entity, once completely empty (

{}

) at the top of the file and once with the correct relationship. Sorry for that 🙏 And thanks for your quick answers !

So, I ran a test with just a few resources (~1000, but only about 100 should be returned) on the lookup resources and we still see a lot of deadline exceeded messages (client timeout is 5 seconds). It seems to build up, in the beginning, everything works like a charm but after some relations get deleted, we get this. We always use an old zookie to not break the cache and actually, it is totally fine if we get resources returned that have already been deleted. They would be filtered on the client side anyways. Any advice what we could do?

We could go towards client side caching and basically everytime we add a resource expand the relations on the resource, but would that even be beneficial?

@User are you running against spicedb or authzed.com?

@User authzed.com, but I abort as soon as i see these issues since I don't want to harm the system

ok, and are relations getting deleted from schema or relationships?

Yepp, they are. But very slowly.

And we are not using the returned zookie from the deletion since I already learned, using the latest zookie can break the cache 😉

my question was meant to clarify whether you were deleting relations or relationships

we call deleteRelationships

we're working on a few things to help with lookup performance

first, we think we've come up with a better way to break lookup into cacheable subproblems, we'll be exploring adding that to spicedb this week

Sounds great 🙂

Yeah, we talked about this I guess.

second, we're currently working on a lookupwatch API and a cache that will progressively update to keep track of the lookup outputs: https://github.com/authzed/spicedb/issues/207

I'm not sure how long it will take to get that second part into authzed.com, since we don't even currently support the watch API on authzed.com

That sounds absolutely perfect, but yeah, time will tell. I also told our customer, that the ultimate fallback solution would be to operate spicedb themselves. But they would like to stick to a hosted solution, as mentioned 🙂

I will take a look at the issue and see if I can help with anything. I doubt it though because of the massive complexity. Thanks for getting back to me this fast anyway 🙂

i think the improved sub-problems will be a big help

Yeah, I already took a look at the dispatcher but I have to dig quite some bit deeper. And then vim broke... Developers problems...

Howdy fellowship of the Z

I started tinkering around on how to automate the inner loop of schema development in our team, and we wanted to essentially have go tests embed a spicedb instance

saw e2e package does this by spawning the process but thought embedding the process would help us easily debug if things don't work as we expect

@User we already do that using the Spice test server, if running via Docker is okay

let me find you an example...

so given there is no API to programmatically a server (as far as I can tell) I was looking a reasonable short part to do that

yeah so I'd actually love to embed the server in our process if possible