Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Add secondary keys #3557

Open
nandorojo opened this issue Apr 4, 2024 · 2 comments
Open

RFC: Add secondary keys #3557

nandorojo opened this issue Apr 4, 2024 · 2 comments
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release

Comments

@nandorojo
Copy link
Contributor

nandorojo commented Apr 4, 2024

Summary

In our product, we very often query items by fields other than their id. It's usually using a slug or shortId. The main motivation is prettier URLs: /@djkhaled for slugs or /invoices/AD34DDAB6 for /invoices/[invoiceShortId]

While our database does (of course) enforce that these slugs are unique, they aren't globally unique. For example, an artist and a venue could have the same slug.

Proposed Solution

While I don't know the right implementation, it would be very useful to approach some sort of clean solution that lets me use secondary keys to access an entity.

For instance, I want artistBySlug(slug: <slug>) to be look for Artist:slug=<slug> without needing to set slug as the key.

Setting slug itself as the key makes me a bit concerned as it isn't truly the unique ID of the item. For instance, if URQL ever adds globally-unique identifiers across objects in the future, I'd want to keep using Artist.id as the actual unique key.

Additionally, we also query directly by ID often (it's either slug or ID) so we'd want the option to do either.

Requirements

This concept has been discussed all over the URQL repo over the years, but I was hoping to bring it up and see if it's something that's actually possible.

The main motivation is simple:

I want to set a query resolver that gets an item from the cache based on a field other than the key:

resolvers.Query.artistBySlug = (result, args, cache, info) => {
  return cache.resolve({ __typename: 'Artist', slug: args.slug })
}
@nandorojo nandorojo added the future 🔮 An enhancement or feature proposal that will be addressed after the next release label Apr 4, 2024
@JoviDeCroock
Copy link
Collaborator

JoviDeCroock commented May 14, 2024

The thing I fear here is that we'd be duplicating a lot of data unless we create some mapping like secondary key --> primary key 😅 I do understand the need for this and how it would simplify a lot of things with querying different facets.

@nandorojo
Copy link
Contributor Author

Yeah I’m definitely sympathetic to that. I think a mapping of some kind could work too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release
Projects
None yet
Development

No branches or pull requests

2 participants