Is the ID! data type alphanumeric?

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.

hi @rachelatmonday

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?

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.

Hi @basdebruin, @anon29275264, @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 were ID
• In some cases, the input type and output type of the same field/argument were not aligned (i.e., the input was Int and the output was ID)
• Even though we used the Int type, 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 ID type 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 Int to ID, 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 🙂

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?

Hello there @anon29275264,

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

Hey @PluginGenie @anon29275264 @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

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.

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.

It would be useful to have some indication, e.g. “we do not intend to have ids longer than 20 characters and will issue a migration notice and 6 months’ warning before extending this”

Hello there @IsaacNewton,

Any changes will be announced as soon as possible in our changelog so you have as much time as possible to prepare anything you want to for the change.

Cheers,
Matias