GNU Social follow requests IDs do not fit in database model #146

Closed
opened 2022-09-12 00:18:11 +00:00 by helene · 3 comments
Contributor

GNU Social follow request IDs tend to be much longer than 128 characters and as such cannot fit within the database model's limit of 128 characters, which will cause the follow request to never be handled.

@Column('varchar', {
length: 128, nullable: true,
comment: 'id of Follow Activity.',
})
public requestId: string | null;

Related issue: https://github.com/misskey-dev/misskey/issues/9086

GNU Social follow request IDs tend to be much longer than 128 characters and as such cannot fit within the database model's limit of 128 characters, which will cause the follow request to never be handled. https://akkoma.dev/FoundKeyGang/FoundKey/src/commit/406be6b2136faa9232d8fcf7ecb6fcbfec20a8fe/packages/backend/src/models/entities/follow-request.ts#L42-L46 Related issue: https://github.com/misskey-dev/misskey/issues/9086
helene reopened this issue 2022-09-12 00:18:52 +00:00
Owner

Know how big we can expect GNU Social's follow request IDs to be?

Know how big we can expect GNU Social's follow request IDs to be?
Author
Contributor

Know how big we can expect GNU Social's follow request IDs to be?

The referenced issue is giving the following example:
https://gnusocial.jp/follow_from_https%3A%2F%2Fgnusocial.jp%2Findex.php%2Fuser%2F9200_to_https%3A%2F%2Fmewl.me%2Fusers%2F5b6bb2cada8b912b16218d34
So, pretty long, I'd say... 512 would probably be enough, I think, and most importantly would match what other entities have for ID length

> Know how big we can expect GNU Social's follow request IDs to be? The referenced issue is giving the following example: `https://gnusocial.jp/follow_from_https%3A%2F%2Fgnusocial.jp%2Findex.php%2Fuser%2F9200_to_https%3A%2F%2Fmewl.me%2Fusers%2F5b6bb2cada8b912b16218d34` So, pretty long, I'd say... 512 would probably be enough, I think, and most importantly would match what other entities have for ID length
Owner

URLs have a practical browser-limit of around 2000 chars, and 2048 chars in XML sitemaps' <loc>.
As such, I think making any URL-related fields that we receive from remote to be varchar(2048) is reasonable.
Besides that, all non-remote text fields should likely be TEXT, which is "immeasurably faster" according to postgres devs (and as discussed in irc).

URLs have a practical browser-limit of around 2000 chars, and 2048 chars in XML sitemaps' `<loc>`. As such, I think making any URL-related fields that we receive from remote to be `varchar(2048)` is reasonable. Besides that, all non-remote text fields should likely be TEXT, which is "immeasurably faster" according to postgres devs (and as discussed in irc).
norm closed this issue 2022-09-12 17:48:38 +00:00
Sign in to join this conversation.
No labels
feature
fix
upkeep
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: FoundKeyGang/FoundKey#146
No description provided.