Backend: Update the releases logic in catalog resources to use the Version association
Summary
The following discussion from #429279 (comment 1620838016) should be addressed.
@fabiopitino
: The GraphQLResourceType#versions
andlatest_version
currently return aTypes::ReleaseType
because that's what we have until we create records incatalog_resource_versions
table. At that point we should only pull data fromCatalog::Resource#versions
association and not releases.I'm noticing actually that we have
versions
andlatest_version
methods inCatalog::Resource
that return releases. These need to be changed to use the association. Thehas_many :versions
association I think is not currently used because theversions
method overrides that.
@lma-git
: Yes, as far as I'm aware, the intention was to convert Release to Version after we establishedcatalog_resource_versions
and related processes. I think the conversion needs to be a VerifyP1 issue that follows Backend: Scan a catalog resource for components (#415413 - closed), if it's not already created. cc@lauraX
@avielle
We'll likely need to do something like the
Release.latest_for_projects
query for theVersion
model. This query is efficient because we provide a set # of projects and only return 1 release per project.However, with Versions, we'll inevitably have to join
catalog_resource_versions
withreleases
, and I think we'll face the same query performance problems as we have with joiningcatalog_resources
andprojects
.
Proposal
- Update the releases logic in the
Ci::Catalog::Resource
model to use the Versions association. - Update the
Ci::Catalog::Resources::Version
model so that it has similar methods as theRelease
model, adapted for Versions. - Update the resolver logic for the GraphQl fields
versions
andlatest_versions
in ResourceType to use Versions. (This will likely involve creating a newCi::Catalog::Resources::VersionsFinder
finder class.) - Update
InstancePath
to use the latest Version if the project is a catalog resource.