[Feature] Generalized support for external IDs

[stg-annon]

Is your feature request related to a problem? Please describe.
Stash currently only supports the ability to store external ids from stash-boxes, this feature request is to allow for the stash_id concept to be generalized to allow for other external sources of metadata

Describe the solution you'd like
the stash_id tables in stash to allow for alternative links or an alternative table be created e.g.

if a user wants to use TPDB for metadata an entry into either table it could be entered like the following

{item}_id	endpoint	external_id
1234	api.metadataapi.net/{item}/	a1991648-22ce-11ec-9621-0242ac130002

This concept could also be extended to other external links, like links to the media source, social links, etc. like described in in #1868

Describe alternatives you've considered
Storing this external match data in a separate DB, this is not ideal because it does not integrate with the stash API or stash UI

[laurus-lx]

FYI - while we are waiting for stash to officially support this, there is a way to add performer handles as is - open stash db in your favorite admin tool (can recommend DBeaver) - add URLs to stash_id table and they'll show up in performer page under stash_id links

https://discord.com/channels/559159668438728723/559399634318131210

[philpw99]

As a filemaker database administrator, I don't agree with this solution. StashID is there for stash-box, not for this purpose.
Using StashID to do it, is like an abuse.
It's way better to create a new field for this, like "Other IDs", or put those links in Details in a format like:

URL_ID: thenude.com : Mia_23199
URL_ID: iafd.com : mia_08_latvian
URL_ID: twitter.com : quattropeliite1
URL_ID: instagram.com : quattropeliite
URL_ID: indexxx.com : mia-mayblack

[SmallCoccinelle]

I like the idea of having a general way to refer to some external ID.

There are some details regarding implementation which can matter, depending on how SQLite stores data:

• If columns aren't compressed, repetition in columns can take up some extra space for no good reason. Posgres has TOAST, which somewhat alleviates this problem. It's very storage dependent. Column-oriented stores tend to not care too much here.
• In Postgres, I'd definitely start with an (indexed) jsonb column for this, but I'm not sure SQLite's JSON extension is adequate... and it's a new extension.
• Getting this normalized will be important if dynamic extension is desired.

... and so on.

It might also hinge on us rewriting some code before this can be tackled. But I don't know enough about the code base (yet) to have an opinion worth its salt here.

[WithoutPants]

I think generalising (and renaming) the _stash_ids tables is a good idea and will allow better integration with the scraper system. I do however think that it should be separated from a generalised external link table.

[stg-annon]

I think generalising (and renaming) the _stash_ids tables is a good idea and will allow better integration with the scraper system. I do however think that it should be separated from a generalised external link table.

I agree, They are similar but different things and should be handled differently, would the handling of links be better suited in an entirely different issue?

[WithoutPants]

I thought there was, but apparently I was wrong. Yes, there should be another issue for handling URLs.