<div dir="ltr">The Rubygems api includes sha as part of the metadata for a gem. Couldn't you use that as part of the natural key?<div><br></div><div>I'm surprised that Chef's supermarket API doesn't include this as well. Maybe we could open a feature request?<br><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 8, 2019 at 2:50 PM Simon Baatz <<a href="mailto:gmbnomis@gmail.com">gmbnomis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 08.01.2019 17:16, Jeff Ortel wrote:<br>
><br>
><br>
> On 1/3/19 1:28 PM, Simon Baatz wrote:<br>
>> On Thu, Jan 03, 2019 at 01:02:57PM -0500, David Davis wrote:<br>
>>>     I don't think that using integer ids with bulk_create and<br>
>>> supporting<br>
>>>     mysql/mariadb are necessarily mutually exclusive. I think there<br>
>>> might<br>
>>>     be a way to find the records created using bulk_create if we<br>
>>> know the<br>
>>>     natural key. It might be more performant than using UUIDs as well.<br>
>> This assumes that there is a natural key.  For content types with no<br>
>> digest information in the meta data, there may be a natural key<br>
>> for content within a repo version only, but no natural key for the<br>
>> overall content.  (If we want to support non-immediate modes for such<br>
>> content.  In immediate mode, a digest can be computed from the<br>
>> associated artifact(s)).<br>
><br>
> Can you give some examples of Content without a natural key?<br>
<br>
For example, the meta-data obtained for Cookbooks is "version" and<br>
"name" (the same seems to apply to Ruby Gems). With immediate sync<br>
policy, we can add a digest to each content unit as we know the digest<br>
of the associated artifact. Thus, the natural key is "version", "name",<br>
and "digest"<br>
<br>
In "non-immediate mode", we only have "version" and "name" to work with<br>
during sync. Now, there is a trade-off (I think) and we have the<br>
following possibilities:<br>
<br>
1. Just pretend that "version" and "name" are unique. We have a natural<br>
key, but it may lead to the cross-repo effects that I described a while<br>
ago on the list.<br>
2. Use "version" and "name" as natural key within a repo version, but<br>
not globally. In this scenario, it may turn out that two content units<br>
are actually the same after downloading.<br>
<br>
I prefer option 2: Content sharing is not perfect, but as a user, I<br>
don't have to fear that repositories mix-up content that happens to have<br>
the same name and version.<br>
<br>
There is also an extension of 2., which allows content sharing during<br>
sync for immediate mode. Define a "pseudo" natural key on global <br>
content level: "version", "name" and "digest". "digest" may be null. Two<br>
content units are considered the same if they match in all three<br>
attributes and these attributes are not null. But even in immediate<br>
mode, the artifact will not be downloaded if "name" and "version" are<br>
already present in the repository version the sync is based on. A<br>
pipeline for this could look like:<br>
<br>
    def pipeline_stages(self, new_version):<br>
        pipeline = [<br>
            self.first_stage,<br>
            QueryExistingContentUnits(new_version=new_version),<br>
            ExistingContentNeedsNoArtifacts()<br>
        ]<br>
        if self.download_artifacts:<br>
            pipeline.extend([ArtifactDownloader(), ArtifactSaver(),<br>
                             UpdateContentWithDownloadResult(),<br>
QueryExistingContentUnits()])<br>
        pipeline.extend([ContentUnitSaver()])<br>
        return pipeline<br>
<br>
QueryExistingContentUnits(new_version=new_version) associates based on<br>
the "repo version key",<br>
QueryExistingContentUnits() associates globally based on the "pseudo<br>
natural key" (digest must be set to match at all)<br>
<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>