> * I kinda don't like the tree of files in git. It would work, but it seems poor, like we don't know how to use a database. Along with just strange to work with.
We could use Git repo of yaml files as the basis but import data upon each commit for each branch into a locally mounted sqlite DB. Commits would be rejected if the import could not be completed. Then setup just a tiny API upon that sqlite DB served by some micro webapp. Access control, versioning and write access would be handled by Git, but user-friendly, fast, read-only data access would be handled by the sqlite + http API pair. The Git backend can also probably also added later. I am writing this because I think it's an interesting option from the technical perspective, not because I would be actually involved with PDC at the moment. I just wanted to share the idea in case somebody finds it applicable. clime On Mon, Apr 23, 2018 at 7:34 PM, Ken Dreyer <ktdre...@ktdreyer.com> wrote: > On Sun, Apr 22, 2018 at 2:23 AM, Stanislav Ochotnicky > <sochotni...@redhat.com> wrote: > > The difference is that PDC rpm-mappings API endpoint was result of two > > sources: > > * Manual per-rpm mappings (overrides) - this is sort of suitable if you > > have a product with just a couple source packages so it's manageable > > this way (i.e Ceph case) > > * Results of compose metadata import - this is what Fedora/RHEL uses > > because several thousands of source packages are not manageable > > one-by-one by humans manually. > > > > You could still make a system that would create "PRs" for the generated > > files for second case, but then querying the current state will still be > > a bit tricky. I guess... > > Yeah, the fact that we have (at least) two different input and storage > methods there is a lot of complexity. I'm not sure that's a good > design in 2018. > > Regardless, you're right, I'm envisioning that we'd have a tool to > generate the data commits and PRs (or just commit + push directly). > PDC had included its own rudimentary form of version control for > auditing and message bus integration. Git's experience is much richer. > > - Ken > _______________________________________________ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-leave@lists. > fedoraproject.org >
_______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
