Search/ImportedFile: rename build to sync_id

[stsewd]

What's the problem this feature will solve?

Currently our ImportedFile model and Page index have an attribute named build, which is the build id from where the files are generated.

readthedocs.org/readthedocs/projects/models.py

Line 1358 in 53e21bb

build = models.IntegerField(_('Build id'), null=True)

We use this ID not to track the build itself, but to allow us to delete the previous objects after we have successfully created the previous ones. The build ID works great, except that in case of a re-index we won't trigger a new build, so the build ID won't be changed, leaving no way for us to identity the old files from the new ones.

Describe the solution you'd like

Instead of tracking the build ID, just have a new field specific for the purpose of tracking the files generated from the current task instead of the build.

And instead of using a numeric field, we can probably just use a random string, which is easier to generate without having to query for the current sync number, and also has fewer chances of colliding with another task. Can also just be the current date.

To avoid downtimes, we won't "rename" the field, but just create a new one, and use that instead of build, and after the next deploy we can remove it.

Alternative solutions

Just keep the field named build, even if it doesn't exactly maps to a build.

Additional context

#10696

[humitos]

And instead of using a numeric field, we can probably just use a random string, which is easier to generate without having to query for the current sync number, and also has fewer chances of colliding with another task. Can also just be the current date.

I think we can use a UUIDField for this.

Just keep the field named build, even if it doesn't exactly maps to a build.

Naming things that mean something different than its name it's pretty confusing. I'd prefer if we change them. While reviewing the PR I thought it was a pretty dark hack or even an error. Without your explanation I would have been thinking the same. I'm sure that next time I read this code I will think it's broken if we don't rename the field 😄