On Thu, 2023-09-14 at 07:41 +0200, Tomas Hrcka wrote: > Ok, now we are on the same page. > > On Wed, Sep 13, 2023 at 8:04 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> > wrote: > > > On Wed, 2023-09-13 at 16:49 +0200, Tomas Hrcka wrote: > > > I thought this was exactly the JSON blob we will implement, If you look > > at > > > the model of PDC > > > > > https://product-definition-center.github.io/product-definition-center/_images/overview.svg > > > > > > Those endpoints are covered by relations Release, Compose, RPM through > > some > > > others. > > > The PDC approach is more or less a normalized RDBMS model. > > > This should be replaceable by a much simpler denormalized approach and > > > create one entry for each compose with all the data in one place. > > > > That's missing the 'composes' endpoint use (#1 in my list below). Not > > sure if that's your fault or mine, sorry if I left it out of a previous > > list. > > > > Does your replacement plan cover the "previous_release" use case, where > > we need a list of all the composes for each release in the order they > > happened? > > > > > Yes idea was to have the compose_id as a document root since it is unique > for each compose. > something like this: > > Fedora-Rawhide-20230913.n.0:{ > compose_related_metadata:[metadata0:metadata,metadata1:metadata] > rpms:[nvr:other_rdata,nvr1:other_rdata1] > images:{Fedora-Sway-Live-x86_64-Rawhide-20230913.n.0.iso:"some metadata"} > } Sure, that works. These dicts should just be straight dumps of the metadata files from the composes - composeinfo.json, rpms.json and images.json - e.g. the ones at https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20230913.n.0/compose/metadata/ . I'm pretty sure that's what they are in PDC already. Note, I still don't think this covers my case #1 exactly: well, it would probably make cid_to_label possible, but as described, I'm not sure it would make label_to_cid possible. We can query PDC with a release number and a label - a label is something like Beta-1.1 - and it will return a single compose, from which we can read the compose ID. If the proposal is essentially just a JSON dict whose keys are compose IDs...well, I suppose technically we could grab the whole thing and do some operations on it to find the compose with a given label, but it's a bit more awkward than just querying. And if it's just a flat dict of every compose ever, presumably it'll be paged, and finding the one you want might take a while? -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx https://www.happyassassin.net _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
