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

    The point tho still stands - why go relational for this?? The answer that this embedded sql-compatible engine make for a good key-value store doesn't satisfy my curiosity. There are modern and capable BDB alternatives - that what was actually implied. So it must be more than license for sure..
    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:

    https://bugzilla.redhat.com/show_bug.cgi?id=1086784





    Comment


    • #32
      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


      • #33
        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


        • #34
          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


          • #35
            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:
            https://bugzilla.redhat.com/show_bug.cgi?id=1086784
            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


            • #36
              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


              • #37
                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; 03-23-2020, 05:45 PM.

                Comment


                • #38
                  afaik there is a fork of LMDB

                  Comment


                  • #39
                    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


                    • #40
                      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