Change older Paperclip database migrations for consistency

[ClearlyClaire]

First part of an alternative to #29263, as discussed in #30203 (comment)

cc @mjankowski

[mjankowski]

Is the idea here to focus more narrowly on the schema/migration disconnect (by restoring old migrations to their original output), and either not bother with, or at least skip for now, the bigint solution to the potential size issue?

[ClearlyClaire]

What potential size issues are you referring to?

[mjankowski]

Sorry, I just meant that there were sort of two issues dealt with in the migrations:

• The consistency issue of the changing column type in the paperclip migrations meaning that the migrations were generating a different schema.rb than what was actually in the repo schema.rb (due to older vs newer versions)
• The actual issue that the paperclip change was dealing with (the int type limiting the ceiling of storable file sizes)

So I was asking if the plan here is to deal with the first issue by changing the old migrations, and ignore the file size storage issue (maybe this is OK ... I think it's a ~2GB size where you hit the limit, which is well above the default limits for these attachments...)

[ClearlyClaire]

Yes, I don't think we have a need to go to bigint, the integer limit is basically 2GB. Our current limit for the largest file types is 99MB.

[mjankowski]

Cool - in that case I agree with the already done revert, and with this approach to aligning the old migrations with the schema.

[sinoru]

Yes, I don't think we have a need to go to bigint, the integer limit is basically 2GB. Our current limit for the largest file types is 99MB.

@ClearlyClaire @mjankowski Is this not applied to Backup? Just for confirmation.

[mjankowski]

@ClearlyClaire @mjankowski Is this not applied to [Backup]

The dump_file_size column on backups table is already a bigint.

[sinoru]

@ClearlyClaire @mjankowski Is this not applied to [Backup]

The dump_file_size column on backups table is already a bigint.

Oh, That's fine...