mirror of
https://github.com/supabase/supabase.git
synced 2026-10-15 06:09:08 +03:00
CharisandJoshen Lim
000c79e22b
The global storage size validation depends on an unpaginated buckets query to determine whether it is lower than any individual bucket's cutoff. This causes a problem for users with tens of thousands of buckets. There's a bit of a UX/performance problem here, because in order to determine whether any bucket's `file_size_limit` exceeds the global setting, we need to get the max `file_size_limit` of `storage.buckets` -- however, that column is not indexed. My workaround is: - Below a certain threshold (10,000) buckets, the query for max `file_size_limit` is automatically run on form submit. - Above that threshold, the user must confirm whether they want to run the query. They're still allowed to change the storage config without running it -- this does open a loophole where they can have a global storage setting lower than an individual bucket's file size limit, but though this is a potentially confusing situation, it's not strictly an error. --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
21 lines
706 B
TypeScript
21 lines
706 B
TypeScript
import { sqlKeys } from '../keys'
|
|
|
|
export const LARGEST_SIZE_LIMIT_BUCKETS_COUNT = 50
|
|
|
|
/**
|
|
* SQL to get the storage buckets with the largest file size limits.
|
|
*
|
|
* This query is unoptimized and should not be automatically called because
|
|
* there is no index on `file_size_limit` in the `storage.buckets` table.
|
|
*/
|
|
export const getLargestSizeLimitBucketsSqlUnoptimized = /* SQL */ `
|
|
SELECT id, name, file_size_limit
|
|
FROM storage.buckets
|
|
WHERE file_size_limit IS NOT NULL
|
|
ORDER BY file_size_limit DESC
|
|
LIMIT ${LARGEST_SIZE_LIMIT_BUCKETS_COUNT + 1};
|
|
`.trim()
|
|
|
|
export const getLargestSizeLimitBucketsKey = (projectRef: string | undefined) =>
|
|
sqlKeys.query(projectRef, ['buckets-with-largest-size-limit'])
|