I guess the difference to me personally is that Tiger Cache is optional, so you're opting into that complexity.

oooh got it 💯

From a community adoption stand-point, it would be nice to have a more official Kubernetes based deployment methodology. Lots of platforms are moving that direction. Having that streamlined deployment an install away with something like Helm would help adoption a little more I think, so it's something ya'll might consider again. Sounds like you've already taken the stance of keeping it simple and not supporting that at this time, which I can understand. Since I need it, I'd be happy to build a statefulset based Kubernetes deployment manifest for a multi-node spicedb instance. I'll probably use Helm as it is one of the more adopted tools in the toolbox for managing Kubernetes deployments. If ya'll would like to reference it in your docs or whatever you can do so.

We're gearing up to deploy a multi-node geo cluster at Adobe within our Kubernetes based platform, which is why I asked.

Yeah, we understand the value. What I want to avoid, which has been my experience in the past, is that your issue tracker becomes the ops team for everyone using those manifests. It might be worth still us accepting upstream and waiting to see if it becomes a problem.

The burden of managing those ops related issues would definitely be a pain. Thanks for the context. I see where you're coming from now. I suppose if you get enough interest in a Kubernetes based deployment option, then that'll be a good indicator that it's worth the investment at that point. Thanks Jimmy

Looking forward to seeing what you come up with!

a lot of the ops issues come from things external to spicedb that don't have just one answer in kube: spicedb should run with tls, but you might not manage certs with cert-manager. you have to route traffic to spicedb, but you have your pick of ingress, and they all have tradeoffs. one thing that's nice about spicedb at the moment is that it's simple to run with basic kubernetes constructs (deployment + service). it's not as obvious (yet) how best to support these other ops concerns, when there are so many user / environment choices at play

I tried to run this code @User @User , spicedb is in container with postgres , it did not go through . Meaning I did not get back to lookup once that function was kicked in and was thrown out. The code does not use ZedTokens , is that not relevant to this case.? The depth of nesting starting from root is pretty deep.

WARNING: RPC failed: UNAVAILABLE: Connection closed after GOAWAY. HTTP/2 error code: NO_ERROR

, subsequent runs did get me back result as

INFO: Response: resolved_object_ids: "1"
revision {
  token: "CAIaCAoGMjAxNTU4"
}

, In reference to the code , the setlimit()` is about the depth 2 which lookup gets performed ? guess might want to try with v1 and see if that is different @User what is the expected output. Should it be set of documents to which the user has write permission?

Yes, the list of writable documents was what I need. In the code, I was trying to build a document hierarchy in a tree manner. Firstly, I created a binary tree and I assigned write permission to the very top node, all descendants inherit permission from the top. Secondly, I tried to look up permitted nodes against the whole tree. This is an extreme case in my product, which is currently running with around 40 millions of documents…

Thanks @User but it returns only the top most document I guess not all the documents in question , which is rot relationship but a check on document number 10000 does return true through cascade. I am interested as I have use cases related documents with a fanning tree

Yes I realized that, still no idea how to deal with this case. Currently the implementation is to store the tree and check through the nodes, remove those are not authorized… please let me know if you have better idea

would it make sense to create resource groups with cross graph relationship and include exclude as a function of user group and resource group more like create buckets and doing intersection. It might be then case of shifting relationships I guess

Sounds interesting, do you have some kind of demo for that? Maybe I could build some thing on top of it

So I'm still trying to work out the data sync problem for our SpiceDB project. The reason we can't do it the normal way (that is, in a db transaction in the app at the time of the update) is because we also have data that's being sideloaded into our db, continuously, using a binlog on a legacy MySQL server (Amazon DMS continuous migration), and this bypasses our app completely.

So I tried to solve this with row-level triggers to adjust

relation_tuple

to stay in sync with row updates. This turned out to be a complex nightmare of PL/SQL code that wasn't solvable in a practical timeframe.

Then I tried query-level triggers that just take a diff of a database view and

relation_tuple

, and update

relation_tuple

to be in sync each time a query ran. This worked but it was slow; I didn't know how slow, however, until we tried to run it on real data this week. The naive trigger timed out; our DB guy was able to tune it to 5 seconds per update, but 5 seconds is still way too slow.

I'm now having our DB guy look into using Amazon DMS Continuous Migration to update SpiceDB from Postgres the same way we update Postgres from MySQL, but if that fails, does anyone have any other ideas?

I asked about this (https://github.com/authzed/connector-postgresql) awhile back but it sounded like that was not being actively developed and had a semi-intractable bug.

At this point I'm about to fork SpiceDB and alter it to know about our relational schema.

@User if you end up forking SpiceDB to accomplish this, we would be very interested in following along, possibly providing guidance with an eye toward how this could be generalized. In the past we have shied away from pretending an existing database is a big collection of relationships because we can't do point-in-time queries, which is critical for scalability of Zanzibar

Oh good point. What suffers in my application if I lose point in time queries?

Well if you don’t have snapshot queries you could open yourself up to the new enemy problem by reading things at various different commits. Performance should be fine for caching if you just always return the latest data even if spicedb asks for older data, assuming your database can keep up.

👋🏻 I'm looking to create a test suite that validates our schema as we develop our own fork with support for Vitess. In order to develop that test suite, I used

dockertest

(just like your integration tests) to pull the spicedb image and run

serve-testing

. I focused in

serve-testing

. as a means to get quick feedback while developing the schema tests in Go. One of the things of the plumbing that has to be considered is waiting for the container to be ready. I initially created a health-check with

dockertest

. doing

SchemaRead

. RPC. Then I learned about grpc Health checks, so I introduced that. Unfortunately, I learned that

serve-testing

. does not wire up the grpc Health Check. Would that be a sensible contribution?

reflecting a little bit on that contribution ☝️ I feel like it's not super useful when I still have to do a write + read with full consistency in order to guarantee "spicedb and the schema are ready for the tests to execute!"

Once the write schema succeeds you should be good to go

@User that's not what I experienced. When I try to do a subsequent

Check

, spicedb errors out indicating the type I specified is unknown. @User pointed out:

schemas don't have revisions (in the API, they do internally)
so you can't write a schema and then get data "at" that schema

What consistency are you using for the check?