[Pulp-list] unit association attributes

[Dennis Gregorovic]

In the case of ISOs, we would use that metadata to present information
to users.  How something is described or how items are grouped together
could vary from one repo to another.  In some ways this is analogous to
comps.xml files.  comps.xml files are specific to a repo and they
provide a way to layer additional metadata (groupings, default type,
etc) onto the RPMs in that repo.

The ability to have multiple unique units that reference the same file
is an interesting idea.  That may solve what I am looking for, though I
do wonder about the complexity that it may introduce.

On Thu, 2014-03-13 at 11:24 -0400, Michael Hrivnak wrote:
> In order to better understand the goal and to come up with a solution
> that will be valuable for common use cases, can you elaborate on why
> you would want a description (or other metadata field) to be different
> from one repo to another?
> 
> I'm wondering if the best approach will be to push data the other
> direction; to come up with a more general storage solution where
> multiple unique units might be able to reference the same file. We
> have other use cases for wanting additional/better storage options, so
> this might be a natural fit for that work. This would let relationship
> objects continue to only store data about the relationship itself, but
> brings up new questions of how to define uniqueness among units.
> 
> Michael
> 
> ----- Original Message -----
> From: "Dennis Gregorovic" <dgregor at redhat.com>
> To: pulp-list at redhat.com
> Sent: Thursday, March 13, 2014 11:09:10 AM
> Subject: [Pulp-list] unit association attributes
> 
> Hi,
> 
> I'm interested in exploring the option of having attributes that we can
> set on unit associations.  For example, let's say that I have an ISO
> which is mapped to two different repos.  I want to provide a description
> of that ISO, but the description would be different in repo A than in
> repo B.  
> 
> Currently, repo_content_units contains the following fields:
> created
> id
> owner_id
> owner_type
> repo_id
> unit_id
> unit_type_id
> updated
> 
> To keep things simple, a single 'notes' field could be added to this
> table like the notes field that is available on repos.  
> 
> A more structured approach would be appealing, but could quickly get
> complicated since the set of desired fields would vary by content type.
> 
> -- Dennis
> 
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list