Re: Database design and Target objects

[Michael Wood <michael.g.wood@intel.com>]

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