Re: PDC replacement proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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
> > > 
> >
> > > 
> > > 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
. 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: | Mastodon: @adamw@xxxxxxxxxxxxx

devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam, report it:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux