SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions.

SpiceDB

I think it’s possible by walking groups back in which the user is a manager

<@1053919393140187136> https://play.authzed.com/s/DdBT3FGm7fd8/schema I think this might be matching what you expect?

its not the more refined way, but I wanted to see if I could get something working

When would something like this happen? (and what's the recommended course of action?)
```2 UNKNOWN: max retries exceeded: unable to write relationships: ERROR: could not serialize access due to read/write dependencies among transactions (SQLSTATE 40001)```

I'm trying to seed our prod relations into spicedb (postgres datastore)

ah found the problem - i have a lot of resources that *all* users have access to. I'm using the `user:*` subject to denote these, and while seeding i was parallelizing the migration of around 1K resources at a time. since this was operating on multiple of these `user:*` objects, this was happening. i'm not sure why this didn't happen the first time I started the seeding though, this was around the 4th/5th time i ran the script and started seeing this problem

that seems to pose a problem actually, if i cant parallelize at all, then it'll take a really long time. is this expected behaviour? 2 resources that the same subjects have a relation with can't be added in parallel?

Hello,
Any view how to delete the Spiceb schema via rest api or cli ? I  am using PostgreSQL and had a specific schema loaded. I wish to delete the same and push a new one which seems to fail. 

Don't see delete API nor via zed cli any option to delete ? Any view ?

👋🏻 there is no delete operation because the write schema API method replaces the entirety of the schema stored. If you are hitting an error is because you have relationships stored, so you'll need to first delete relationships and then write the new schema

this is a mechanism to prevent unitended data loss. SpiceDB checks what `definition` are deleted on your WriteSchema call, and checks if there are any relationships associated with any of the `relation`s in that `definition`

I deleted all required relation which were based on say xyz schema , now via rest api I am able to write new schema and 200 response , but now if I try to read the schema neither I see old xyz schema nor the new one ? 
and error says no schema defined with 404 error code

`{
    "code": 5,
    "message": "No schema has been defined; please call WriteSchema to start",
    "details": []
}`

<@905388561250025492> <@444996680530657281>

are you using the same prefix as before or a different one?

Do you mean namespace ? Yes I am using different namespace, I was under assumption that if all existing schema specific relation are deleted then we can update the existing schema and add more definition which could be under different namespace

Yeah no, I believe you have to use the same namespace prefix

Think the prefix as your tenant identifier. Everything you write has to have that prefix.

Let me share an example, 
If I use rest api to write following schema [v1/schema/write]  and fetch the same via read [v1/schema/read] 
it fails 
But if same schema is pushed via Python script and then read via rest read api , it works .

`curl --location --request POST 'http://localhost:8443/v1/schema/write' \
--header 'Authorization: Bearer graphToken' \
--header 'Content-Type: application/json' \
--data-raw '{
    "schemaText": "definition authznamespace/namespace {}\n\ndefinition authznamespace/user {}"
}'`

Any reason why write of above schema via rest api is not working ? [Note, rest api response is 200 ]

<@905388561250025492>

<@952176071749541969> it probably wants `schema_text`

Just tried that as well and it didnt work , still returns 200 but then the read is not returning same schema .
Also the swagger api says it has to be `schemaText`

https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.SchemaService.WriteSchema

the reason it didn't give an error is that an empty schema is valid; its just ignored

Team - Authzed serverless - what is the rate limiting you have in place ?

Also interested to hear more about this as it seems I keep hitting some sort of limit on a Development system. Although just assuming since the error I get is UNAVAILABLE with no details at all. So this also makes me wonder if we should get a more specific error when we hit a rate limit?

we've been investigating making the error more specific, but the system we're using to do the limits is currently designed to return UNAVAILABLE by default.

<@444996680530657281> What is the limit at this point ?

We'll DM you limits, as we need to keep them private to avoid abuse we've seen in the past

any suggestions w.r.t this - https://discord.com/channels/844600078504951838/844600078948630559/1054659525141082184 ?

you have overlap in your write calls which is overloading your DB

make sure the relationships being written are not the same

ive deduplicated the relations themselves (if more than 1 of the same subject is in the list, only pick one etc.). but the issue seems to be happening if the same accessor is being updated for different resources in parallel

so i was trying to parallelize the migration by batching 1k resources at a time. the same subject can have a relation with multiple resources, so there might be calls that update the same subject for a different resource happening in parallel - from what I can see, this is causing the transaction locks/retries

you might need to use smaller batches then (or have a larger Postgres install)

that error means postgres can't update the indexes synchronously before timing out

<@802245842077483029> might have some more insights on this

ive gone as low as 100 at a time and run into at least 1 or 2 of these errors - i didn't want to continue with that because missing out 1 or 2 relations every 100 would eventually require running the same thing again

what I did notice was that this didn't happen in the beginning - I migrated around ~900k resources successfully and then this happened all of a sudden

no deleting at all right now, just adding all the relations