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

Use UUID version 5 for node IDs in source/transformer plugins #1853

Closed
KyleAMathews opened this issue Aug 18, 2017 · 14 comments
Closed

Use UUID version 5 for node IDs in source/transformer plugins #1853

KyleAMathews opened this issue Aug 18, 2017 · 14 comments
Assignees

Comments

@KyleAMathews
Copy link
Contributor

This was pointed out on Discord https://www.npmjs.com/package/uuid#version-5

Node IDs should be a) globally unique and b) meaningless so people don't rely on them for anything. Standardizing on UUID version 5 seems like a good way to accomplish this.

Thoughts?

@jquense
Copy link
Contributor

jquense commented Aug 18, 2017

I think we do some amount of regex'ing off the id as a path for documentation on www. but overall I think it's a good idea :)

@KyleAMathews
Copy link
Contributor Author

Who wrote that code??? They should be fired! ;-)

Yeah, though we should probably make this change as part of v2.

@jquense
Copy link
Contributor

jquense commented Aug 18, 2017

it should already be fine to do deep filtering right e.g. internal.path, I find that most of the time I want the ability to search by file path, maybe we should add it automatically where it makes sense?

@KyleAMathews KyleAMathews mentioned this issue Aug 23, 2017
14 tasks
@arlair
Copy link

arlair commented Oct 26, 2017

Hi, I am not sure if I am doing this wrong, but I found it quite useful to be able to specify my own id for a source plugin that used relational database tables. I could make the id based on the table name, row id and a name for my plugin (perhaps with an instance number if it was reusable). Then I don't need to create any hash maps to keep track of the ___NODE relations in the plugin and they can be generated based on the data.

It is also easier to debug the id with an error message something like:

Error: Invariant Violation: Encountered an error trying to infer a GraphQL type for: "data.{tableName}___NODE". There is no corresponding node with the id field matching: "{row id}-{plugin-name}{table name}"

@jquense jquense mentioned this issue Oct 26, 2017
13 tasks
@KyleAMathews
Copy link
Contributor Author

@arlair could you create an issue for the error message? Sounds like a really helpful improvement!

@arlair
Copy link

arlair commented Oct 26, 2017

@KyleAMathews The error already exists :) I was just showing how useful it became when I was able to specify a custom Gatsby id based on what should be unique information, rather than a new generated UUID id that would be harder to identify.

One option might be to build into the API a postfix for the Gatsby Id based on the plugin name and instance and maybe node type? When I first started trying to build a Gatsby plugin, I assumed I was meant to be passing in my own id and it would make it unique based on my plugin instance and the node type in internal.

I think I found it confusing because what turned out to be the Gatsby id was called id and lived in the root of the Node interface and not the internal area, but I've been meaning to write something up separately about that.

@danielfarrell
Copy link
Contributor

I'm taking a go at this one, just FYI.

@KyleAMathews
Copy link
Contributor Author

Thanks @danielfarrell!

@KyleAMathews
Copy link
Contributor Author

Also sent you an invite to Gatsby's core team so you can assign yourself to issues in the future :-)

@danielfarrell danielfarrell self-assigned this Jan 13, 2018
@calcsam
Copy link
Contributor

calcsam commented Jan 26, 2018

Fixed in the PR, closing this

@calcsam calcsam closed this as completed Jan 26, 2018
@KyleAMathews KyleAMathews reopened this Jan 26, 2018
@KyleAMathews
Copy link
Contributor Author

@calcsam @danielfarrell's PR was just to add the new helper function to v1 so this issue isn't done yet as we need to convert source/transformer plugins in v2 over to use UUIDs for ids.

@danielfarrell
Copy link
Contributor

Is there a process that changes flow from master to v2? I can finish this up for v2, but didn't want to duplicate that code if it would flow through.

@KyleAMathews
Copy link
Contributor Author

Yeah, I merge them in :-) Lemme do that real quick.

@KyleAMathews
Copy link
Contributor Author

merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants