🐛 Bug Report: Can't upgrade with long attributes

[stnguyen90]

👟 Reproduction steps

1. Create more than 100 attributes with key that is longer than 35 like iam35characterslonggggggggggggggggg on 1.3.8
2. Upgrade to 1.4.2
3. Run migrate command

👍 Expected behavior

Migration is successful

👎 Actual Behavior

Migration fails with:

Migrating Collection attributes:
100 / 574
200 / 574

Fatal error: Uncaught Utopia\Database\Exception\Query: Invalid query: Invalid cursor: UID must contain at most 36 chars. Valid chars are a-z, A-Z, 0-9, and underscore. Can't start with a leading underscore in /usr/src/code/vendor/utopia-php/database/src/Database/Database.php:4061
Stack trace:
#0 /usr/src/code/src/Appwrite/Migration/Migration.php(198): Utopia\Database\Database->find(Object(Utopia\Database\Document), Array)
#1 /usr/src/code/src/Appwrite/Migration/Version/V19.php(798): Appwrite\Migration\Migration->documentsIterator('attributes')
#2 {main}
  thrown in /usr/src/code/vendor/utopia-php/database/src/Database/Database.php on line 4061

This is because we paginate using a cursor and the $id that is used for the cursor is the $id for an attribute:

appwrite/app/controllers/api/databases.php

Line 117 in 5717fbe

'$id' => ID::custom($db->getInternalId() . '_' . $collection->getInternalId() . '_' . $key),

which means a valid key of length 35 can result in an $id greater than 36 due to the $db->getInternalId() . '_' . $collection->getInternalId() . '_' prefix. Because the $id is greater than 36 chars, UID validation fails.

🎲 Appwrite version

Version 1.4.x

💻 Operating system

Linux

🧱 Your Environment

Tested on 1.4.2

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[fogelito]

utopia-php/database#322

[stnguyen90]

We'll revisit this if we see more demand for this

[stnguyen90]

Re-opening due to another case: https://discord.com/channels/564160730845151244/1249721750778806332

[stnguyen90]

We should be able to bypass this validation error by calling disableValidation() before the migration starts.