Should duplicate store names be allowed?

[gmartin-flexe]

I was using the playground locally and noticed that while the UI doesn't allow me to create two stores with the same name, I could create stores via the API with the same exact name. I then made a call to list stores and validated that there were two different stores with different ids but the same name.

Is there any reason we can't just put a uniqueness constraint on the store name? What use case(s) does having multiple stores with the same name serve?

[rhamzeh]

OpenFGA uses the Store ID for uniqueness, it does not care about the Store Name, that’s just for display purposes.

While we don’t allow it yet, we want to let users update the store name, and we don’t want them to worry about whether that name is “taken” or not
We have additional authorization options in our roadmap, which means some store owners may be able to access only some of the stores. Having CreateStore fail because of some vague uniqueness logic they have no control over would not be a good experience for them

TLDR: Name is metadata for display purposes only, if you are looking for a stable unique identifier, use the Store ID

[gmartin-flexe]

I appreciate the reply, and in the grand scheme of things I don't feel like this needs to change.

That said, "just for display purposes" feels like a good argument for unique names; some users in my organization will not have any context on the store ids, and will only see and interact with store names. Asking them to understand which of N stores with the same exact name they should work with feels unrealistic. The current playground UI agrees with me; it will prevent a duplicated store name if you try to make one there.

I also don't see how the additional authorization options conflicts with name uniqueness; I would actually think it's easier to make sure the right people have the right access to stores when stores are easily told apart by having unique names.

For some context, I am setting up OpenFGA to run across numerous environments, and infrastructure to apply schema changes to stores. If I hadn't checked the API behavior, I would have potentially allowed the creation of many many stores with the same name across a large number of environments programmatically. Ideally I can say "get or create a store named X and then do things with it" and not worry about accidentally introducing many confusing duplicated records.

Again, this isn't a big deal. But if there's no compelling use case that requires duplicated store names, and all users of OpenFGA can avoid some potential confusion/pain by disallowing duplicated store names, changing it feels like a small win for usability.

[fsedano]

@gmartin-flexe @rhamzeh please let me add our use case here, where some uniqueness / predictability would be needed on the store IDs.

When we deploy our environment, which includes multiple separate services and an OpenFGA instance, it can be for a dev environment, for production, e2e and so on.

In the case of a dev environment, we want to offer the user a ready to use policy environment. So, as part of the deployment, latest policy model is loaded, a store is created etc.

The problem here is we want, for development environments, to:

• Automatically create the store if it does not exist
• Use the existing store if it exists (for example, developer re-deploys it's environment, we dont want to lose the data)
• Allow him to switch to a different store if needed.

For that, what we're doing is:

• There's a setting with the desired store name: 'defaultstore' by default
• When enviromnent is deployed, we check if a store exists with that name. If it exists, we return the store ID, else we create and return.
• Application can then use the resulting store ID.

This obviously fails if somebody creates more stores with the same name.

So, we would need either:

• Predictibility in the store ID (allowing us to pass the desired StoreID and error out if it exists)
• Use a unique attribute we can set (name for example).

Hope it helps clarifying the need.

[gmartin-flexe]

@fsedano What you described is exactly what I have implemented, and the exact reasons why I would appreciate uniqueness on stores :)

[github-actions]

It appears this issue has been stale for at least 14 days 🗓️. If no action is taken the maintainer team may consider closing the issue. Please reach out if you need feedback or follow up actions from the maintainer team.

[fsedano]

Folks is there any update on this? I had a chat with @aaguiarz today in Kubecon about this, and I think he tends to agree this is needed / useful. Thanks!

[fsedano]

Also we're facing a similar issue for Model IDs. It would solve a lot of issues if we can make model ID with a user-requested ID. I'll open a separate issue for that.

[FranciscoKloganB]

I suspect the OpenFGA team might be underestimating the value of these requested options.

I’m not suggesting these changes are trivial. I know better than that. I may be missing the bigger architectural picture, but compared to the extremely complex features you’ve already implemented, adding an optional field to the API seems relatively straightforward. 😉

While I understand the preference for ULID as the primary identifier over a user-provided VARCHAR, I struggle to reconcile not having a unique name constraint while simultaneously preventing us from creating stores with predictable IDs.

Our use case is very similar to @fsedano’s. We manage multiple single-tenant environments in the banking sector. Since each tenant has several environments that must be fully isolated, we cannot afford to manually set them up; it’s simply too error-prone.

Because we can't provide a specific ID via the create-store API, we initially tried to resolve IDs by name during application boot. However, we quickly discovered that name lacks a unique constraint. We’ve managed to "hack" a solution by forcing sequential pod deployments in K8S and blocking workers from self-provisioning, but it's far from ideal. We’ve written hundreds of lines of code and built fragile deployment assumptions just to make this work. While a unique constraint on names might be a breaking change, adding the option for a predictable ID is not.

We are eagerly awaiting this change so we can scrap this contrived boot process. Manual workarounds aren't an option for us; banks expect instant provisioning, and they won't wait for us to run manual scripts.