I saw that in the newest API version, many IDs are changing from type [Int] to type [ID!]. Is the type ID! alphanumeric or also an integer? I couldn’t find any documentation for what this data type means.
Hi @PluginGenie,
Great question 
Yes, they are alphanumeric! GraphQL syntax allows for both id: 123 and id: "123", though we advise against treating them as integers. If you store them in your database, you should store them as text.
3 Likes
Thanks, good to know. When we need to store these ID’s in a local database and want to use a varchar, what is the maximum length of those ID’s we can expect?
1 Like
To add onto Bas de Bruin’s great question, are the IDs expected to be in a specific format that doesn’t change? For example, exactly 20 characters long.
The reason I’m asking is because if I knew that IDs were always a certain length, then I could add better validation in my app to ensure a user entered a valid ID.
Also, are existing IDs going to be migrated over to the new ID or will existing IDs remain as integers?
I really appreciate all your help!
@rachelatmonday another question I have is there any plan to transition API responses that currently return integers to strings?
Will the outputs of triggers for integration be changing to strings at some point? (Possibly in a Apps Framework 2.0 situation.)
The recommendation for storing at text in databases, is that due to an expected change to using characters greater than 0-9?
If there is plans at some point to introduce a-Z or even other characters, that will necessitate a lot of code changes because we have been converting strings to numbers since Int types required numbers.
Just need to know how much rework I am expecting.
1 Like
Hi @basdebruin, @codyfrisch, @PluginGenie,
I’m responding to all of you here in one message
In short, we’re implementing this change to align some discrepancies in our schema:
- Some IDs were
Int, while others wereID - In some cases, the input type and output type of the same field/argument were not aligned (i.e., the input was
Intand the output wasID) - Even though we used the
Inttype, the contents were above the 32-bit limit, making them out of compliance with the GraphQL specification
To solve this, we adopted the standard ID type defined by the GraphQL Schema (see docs here).
Candidly, there are some things we can’t commit to as we don’t know the way the platform or company will grow. The shape of our system might have to change at some point, so committing to no changes in specific lengths, formats, types is very difficult.
Here’s what I do know and can commit to:
- The
IDtype is dynamic. It take integers and strings when it’s an input argument. It ONLY returns strings. If your code expects an integer for an ID, change it to a string. - Since we changed some inputs from
InttoID, you don’t need to convert these to numbers since they now accept strings. - IDs should be treated as random alphanumeric strings, and shouldn’t be interpreted/parsed in any way. I know that many of our IDs are numerical, but don’t rely on that pattern. We don’t have a specific maximum ID length or a specific format that we can commit to.
- In 2023-10, every field/argument returning/accepting an identifier will be of type
ID. For example, column IDs are no longer strings. Their “format” will not change, but they will all be strings in responses. This should answer your first question (Cody) and your last question (Oliver).
Of course, if we change the type again in the future, we will treat it as a breaking change and will notify you all well in advance! No changes planned at the moment, but wanted to just clarify.
Let us know if you have any other questions
2 Likes
What about values in non-graphql circumstances such as webhooks where they have been mixed in the past (some triggers return itemId as a string, some as integer)? Will those be standardizing on strings as well?
1 Like
Hello there @codyfrisch,
In the long run we plan to change and improve our webhooks mechanisms.
Having said that, this will not be changing in the near future.
Cheers,
Matias
2 Likes
Hey @PluginGenie @codyfrisch @basdebruin –
I went ahead and made a list of all the fields that are changing type – all of the below are changing from integer to ID. I’ll also add this to our migration guide & release notes soon.
As a reminder, you don’t have to worry about any arguments that change to ID, as this type accepts both integer and string values.
Account >> id
New type: ID
Old type: Int
AccountProduct >> id
New type: ID
Old type: Int
Board >> board_folder_id
New type: ID
Old type: Int
Board >> workspace_id
New type: ID
Old type: Int
Document >> doc_folder_id
New type: ID
Old type: Int
Document >> id
New type: ID
Old type: Int
Document >> object_id
New type: ID
Old type: Int
Document >> workspace_id
New type: ID
Old type: Int
DocumentBlock >> doc_id
New type: ID
Old type: Int
Folder >> id
New type: ID
Old type: Int
Folder >> owner_id
New type: ID
Old type: Int
Tag >> id
New type: ID
Old type: Int
Team >> id
New type: ID
Old type: Int
User >> id
New type: ID
Old type: Int
Webhook >> board_id
New type: ID
Old type: Int
Workspace >> id
New type: ID
Old type: Int
2 Likes
hi @dipro
Thank for that list. From @rachelatmonday remark:
If you store them in your database, you should store them as text.
We need to make a lot of changes in our database. I didn’t see a response to my question how long those ID’s can become (length of the varchar). Any insights to that?
Also, currently we parseInt all the “id’s” when calling the wrapper functions that make the API calls. As ID’s can be alphanumeric in the future we need to change that also I guess and prevent the parseInt.
It would be very helpful if you can write up an extensive guide how to change apps to accommodate this type change and all other changes that needs to be done. It’s very hard to combine the responses to posts like this, the API documentation and the API change list.
1 Like
Good points.
Guide to accomodate this change - it’s on my list! Will be fleshing out the migration guide to include these examples.
Length of varchar – As Rachel said before, it’s not really something we can commit to… I don’t want to tell you “Use 20 characters” and then force you to migrate again. IMO you’ll be safe with a VARCHAR(255) – but if you want to be really safe just use the max length (I think it’s something like VARCHAR(MAX)?) and then never worry about it again.
2 Likes