Database design and Target objects

Database design and Target objects

[Smith, Elliot]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

The Target object in Toaster's database currently has a
license_manifest_path, which is only set for targets which produce images.
(This means that manifest files are treated differently from other types of
build artifact.)

In Toaster's build dashboard, we show this as the License manifest, with a
link.

However, Belen's new designs call for a separate section for manifests,
with links to both the package manifest and the license manifest. This
means linking a Target to another type of manifest.

I can see broadly two ways to do this:

1. Add a package_license_manifest field to the Target object. This fits
with the approach we have for the license manifest and is most expedient,
but feels wrong in terms of good practice for database design.

2. Add a separate category of manifest file objects associated with Target,
into which both license and package manifests are inserted. This feels
better but is much more work and makes the database more complicated than
it already is.

This is partly a general philosophical question: should we start repairing
problems with Toaster's database design now (option 2), or find expedient
solutions which follow existing (though sometimes poor) patterns (option 1)?

My preference is option 2, but the number of outstanding bugs makes me
consider 1 (not just for this bug, but, again, generally).

Any comments would be welcome.
Elliot

-- 
Elliot Smith
Software Engineer
Intel Open Source Technology Centre

[-- Attachment #2: Type: text/html, Size: 1838 bytes --]

Re: Database design and Target objects

[Michael Wood]

On 04/07/16 11:54, Smith, Elliot wrote:
> The Target object in Toaster's database currently has a 
> license_manifest_path, which is only set for targets which produce 
> images. (This means that manifest files are treated differently from 
> other types of build artifact.)
>
> In Toaster's build dashboard, we show this as the License manifest, 
> with a link.
>
> However, Belen's new designs call for a separate section for 
> manifests, with links to both the package manifest and the license 
> manifest. This means linking a Target to another type of manifest.
>
> I can see broadly two ways to do this:
>
> 1. Add a package_license_manifest field to the Target object. This 
> fits with the approach we have for the license manifest and is most 
> expedient, but feels wrong in terms of good practice for database design.
>
> 2. Add a separate category of manifest file objects associated with 
> Target, into which both license and package manifests are inserted. 
> This feels better but is much more work and makes the database more 
> complicated than it already is.
>
> This is partly a general philosophical question: should we start 
> repairing problems with Toaster's database design now (option 2), or 
> find expedient solutions which follow existing (though sometimes poor) 
> patterns (option 1)?
>
> My preference is option 2, but the number of outstanding bugs makes me 
> consider 1 (not just for this bug, but, again, generally).
>
> Any comments would be welcome.
> Elliot
>
> -- 
> Elliot Smith
> Software Engineer
> Intel Open Source Technology Centre
>
>

With this release we are definitely trying to tidy things up, but I 
think option 2 is only a good option if you foresee more manifests types 
coming up in the future. Otherwise for just two types of manifest I 
don't think it matters that much to have an extra field in the Target model.

Michael