Generic keys?

[Ericson2314]

It might be nice to make the key type a parameter on the core interfaces, rather than a fixed type. Different use-cases structure keys in different ways.

I assume there is a more general conversation on when to the new Go generics, but open this to track this specific use case of generics. I'll reference it in other issues.

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[guseggert]

Do you have a concrete use case for this that we can discuss? Or multiple, ideally.

Also note that this would be a costly change since it would require a major version bump, but there are a lot of consumers and migration would take a long time, requiring maintenance of multiple versions of this and datastore implementations.

[Ericson2314]

The concrete use-case I have in mind is https://github.com/ipfs/go-ipfs/issues/8907. This could be accomplished by modifying the key schema to include and optional CID, or making a second type of datastore plugin.

When keys are strings having two types of data store plugins is annoying because the key types are the same even though they logically are not, but perhaps doable. On the other hand, modifying a single datastore plugin interface is an unmitigated disaster because there is no way to add more information to the keys without a breaking change and no compilation failure to alert the use. Well typed keys make such migrations much less dangerous.

[Ericson2314]

It occurs to me that by making a new interface, and then making the original interface a specialization of the new one, that we could avoid all breaking changes?

[BigLep]

@Ericson2314 : this change doesn't need to be made in go-datastore right?

[github-actions[bot]]

Oops, seems like we needed more information for this issue, please comment with more details or this issue will be closed in 7 days.

[Ericson2314]

@BigLep Well you tell me. As described, I would like some current uses in IPFS of this library to use the typed keys variant. I think the current version of this library can also use the type keys variant for deduplication's sake. I could make a new library and send a PR to this library gutting it into a thin wrapper, but is that worth it?

[aschmahmann]

@Ericson2314 as I flagged in the other issue I don't think the datastore is going to give you the information you need for SWH. However, I think the idea here is that you can make new interfaces elsewhere (or in a branch here) and as the use cases emerge they can get evaluated.

For example, if you wanted to use the new datastore type inside of kubo the kubo maintainers would take a look at the use and see if it seems reasonable and maintainable for what you're trying to do.

[Ericson2314]

Sounds good. I meant to float the idea to see if it as something you all thought was plausible/worth considering not get you do the work for me :)

[Ericson2314]

Now that I know about the Blockstore interface this is less urgent.