enh/snowflake ids - #9186
Open
max-nextcloud wants to merge 8 commits into
Open
Conversation
Signed-off-by: Max <max@nextcloud.com>
max-nextcloud
force-pushed
the
enh/snowflake-ids
branch
2 times, most recently
from
September 8, 2026 07:03
1569518 to
c83be29
Compare
max-nextcloud
force-pushed
the
enh/snowflake-ids
branch
5 times, most recently
from
September 8, 2026 11:49
0723ece to
666af57
Compare
max-nextcloud
marked this pull request as ready for review
September 8, 2026 12:26
Do not rely on autoincrement ids, which require shuffling tables around in the migration as some databases cannot change columns to autoincrement. `$document->id` is now a string, which conflicts with the definition in the Entity class. Mute the psalm warning about this for now. Proper solution will be to migrate to the new ORM. https://carlschwan.eu/2026/08/18/modern-stable-apis-for-your-nextcloud-application/ Signed-off-by: Max <max@nextcloud.com>
max-nextcloud
force-pushed
the
enh/snowflake-ids
branch
from
September 8, 2026 13:10
666af57 to
4be7b15
Compare
Signed-off-by: Max <max@nextcloud.com>
blizzz
requested changes
Sep 9, 2026
Member
There was a problem hiding this comment.
Changes look good to me. Claude found a few items:
AttachmentService::cleanupAttachments(int $fileId)is being called with the documentId fromCron/Cleanup:37- Front-end types are not migrated, they still advertize
number - The change to auto-increment in the migration is still in place
It does not work on all database types. Therefore we will use snowflake ids instead. Signed-off-by: Max <max@nextcloud.com>
Signed-off-by: Max <max@nextcloud.com>
Signed-off-by: Max <max@nextcloud.com>
Signed-off-by: Max <max@nextcloud.com>
max-nextcloud
force-pushed
the
enh/snowflake-ids
branch
from
September 9, 2026 12:32
dbc90d3 to
e88c15e
Compare
… fileId Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Member
|
OK, i think my attempt was utter nonsense. But the issue should not really be dependent upon the snowflake ID, but the change in general, and the frontend passing a file id here 🤔 – after all, attachment resolver was left unticked in #9062 (comment), but the Controller changed, so I guess we have to make it work. Max, feel free to drop my silly commit. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
enh(document): use snowflake ids
Do not rely on autoincrement ids,
which require shuffling tables around in the migration
as some databases cannot change columns to autoincrement.
$document->idis now a string,which conflicts with the definition in the Entity class.
Mute the psalm warning about this for now.
Proper solution will be to migrate to the new ORM.
https://carlschwan.eu/2026/08/18/modern-stable-apis-for-your-nextcloud-application/
Todo