oc_filecache: optimization structure > UNSIGNED! #46000
Description
I am working on a project that "hooks" into Nextcloud. All is working quite well, but I just stumbled on something, something easily changed and does no harm and can only improve NextCloud:
There are quite a few 'bigint' field types in 'oc_filecache'.
As far as I know and can see all values are only positive, except size
( -1 for folder) and mtime
could have an negative timestamp)
So making them UNSIGNED would be logical and (with fileid
) would double the theoretical number of files NexCloud could handle!
Also:
Why is a number like storage
a BIGINT? Wouldn't be a SMALLINT (unsigned: 65535) be enough? Or to be on the safe side a MEDIUMINT (unsigned: 16777215 is quite a ridiculous high number, wouldn't you say)?
And mimetype
and mimepart
, wouldn't be a SMALLINT (unsigned: 65535) be a more then safe maximum number?
And storage_mtime
when set to "unsigned INT" the maximum value would be 4294967295 (February 7th 2106) would be more then fine for the next 80+ years!
This would improve the table structure, remove unwanted/impossible values, remove reserved space, thus make it smaler, so faster.
Easy change, easy benefit?
PS: as for mimetype (and others) also other tables can/must be altered (but filecache is one otf the big ones, so has the most to gain)
PS2: also the id
in oc_mail_messages can be set to 'unsigned', doubling the amount that table can hold!
Activity