Announcement

Collapse
No announcement yet.

Fedora Looking To Transition The RPM Database From Berkeley DB To SQLite

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by mos87 View Post

    doesn't really answer the q why would they go for a relational db. "cos everyone's doing that" sort of thing?
    A package manager database seems like a perfect fit for a relational database. I don't know what model they adopted for their internal, but I can think of three tables off hand: transactions (like yum/dnf upgrade, or yum/dnf install foo), packages (foo version 1.1), events (started upgrade transaction, installed foo 1.2, finished upgrade transaction).

    Sure, you can model that with a transactional key-value store without separate tables and SQL. But why would you? You would just be recreating half of an SQL engine in code anyway.

    Plus, Fedora NetInstall images (the smallest they have, as far as I know) already contain libsqlite 3.

    Comment


    • #32
      Originally posted by bug77 View Post
      when your configuration becomes a little to complicated to handle with a .properties or .yaml file.
      Maybe it signals that its time to rethink your model
      Originally posted by bug77 View Post
      the relational nature of the solution may not be used at all.
      the fittest instrument and all that..
      if its just for a select maybe it's too much of an overkill? for a system component too.
      Originally posted by bug77 View Post
      Sqlite is the most deployed DB engine on the planet (a lot of applications manage their settings and other internal data using Sqlite), so if it works for all those people, it can't be the poorest choice for rpm, can it?
      Windows NT is one of the most deployed server platforms too.

      Comment


      • #33
        Originally posted by Michael_S View Post
        Sure, you can model that with a transactional key-value store without separate tables and SQL. But why would you? You would just be recreating half of an SQL engine in code anyway.
        I'd imagine that an SQL engine even an embedded one is much more than that... But mainly I'm curious why it's needed at all for package management. Seems like a case of overengineering.

        Comment


        • #34
          Originally posted by RahulSundaram View Post
          What BDB alternatives did you have in mind? RPM developers have considered several db backends. You can do some quick research to satisfy your curiosity easily. Here is one example:
          Thanks for the link.
          Yeah LMDB is the first that springs to mind.
          But already seeing that they have Howard in that convo you almost could tell beforehand it would probably not end well (i.e. in adoption of LMDB).

          Comment


          • #35
            Last post from the link above:
            And even if all that could be worked around, it's a whole lotta complications to what is otherwise pretty simple scheme, complications which we don't want.

            And then they go and use a general purpose full fledged SQL engine for package management.

            As a side note, there exists a pretty mature fork of LMDB by some Russian engineers, aiming mostly at fixing the various shortcomings (alignment being one of them) of the original engine. (they also did that with OpenLDAP itself). Bit late for that obviously....

            Comment


            • #36
              Originally posted by mos87 View Post

              Thanks for the link.
              Yeah LMDB is the first that springs to mind.
              But already seeing that they have Howard in that convo you almost could tell beforehand it would probably not end well (i.e. in adoption of LMDB).
              https://github.com/rpm-software-mana...9f486e55eac331
              and this https://github.com/rpm-software-management/rpm/pull/902


              Last edited by Anvil; 23 March 2020, 05:45 PM.

              Comment


              • #37
                afaik there is a fork of LMDB

                Comment


                • #38
                  Originally posted by Anvil View Post
                  afaik there is a fork of LMDB
                  Originally posted by mos87 View Post
                  As a side note, there exists a pretty mature fork of LMDB by some Russian engineers, aiming mostly at fixing the various shortcomings (alignment being one of them) of the original engine. (they also did that with OpenLDAP itself). Bit late for that obviously....
                  And here it is - https://github.com/erthink/libmdbx

                  Comment


                  • #39
                    Originally posted by mos87 View Post
                    that'd be it, your better off to ask Panu or the other rpm.org devs about this DB on there mailing list

                    Comment

                    Working...
                    X