PURLDB: Design models to relate sources to binaries

[pombredanne]

A binary JAR is often missing origin and license details. These may be present in the source JAR or a corresponding source repository.

We need to find which are the sources for a binary (and reciprocally) and store this informnation in new PurlDB models to design.

[DennisClark]

I think this should be a very simple table that looks like this:

• binary_package (this is the "to" side of the relationship)
• source_package (this is the "from" side of the relationship)

and each one identifies the specific object, using PURL if possible, that is participating in the relationship.

[DennisClark]

let's call the new table package_relationships

[JonoYang]

We have a model that's been commented out in purldb/models.py named PackageRelationship (https://github.com/nexB/purldb/blob/main/packagedb/models.py#L729), which can be used as a base or inspiration for what we're doing here.

[pombredanne]

I think this should be a very simple table that looks like this:

* binary_package   (this is the "to" side of the relationship)

* source_package  (this is the "from" side of the relationship)

and each one identifies the specific object, using PURL if possible, that is participating in the relationship.

@DennisClark Should we keep the names a bit more generic like to and from? or origin and target or source and target?

[DennisClark]

@JonoYang "to" and "from" would work just fine !

[tdruez]

See also the prototype model on the ScanCode.io side (which relate resources) @ https://github.com/nexB/scancode.io/blob/659-d2d/scanpipe/models.py#L1899

[pombredanne]

This is completed but not merged
This is in https://github.com/nexB/purldb/compare/49-on-demand-mining and https://github.com/nexB/purldb/compare/75-api-index-request and https://github.com/nexB/purldb/compare/packagedb-model-update
Closing now!