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

  • Anvil
    replied
    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

    Leave a comment:


  • mos87
    replied
    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

    Leave a comment:


  • Anvil
    replied
    afaik there is a fork of LMDB

    Leave a comment:


  • Anvil
    replied
    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.

    Leave a comment:


  • mos87
    replied
    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....

    Leave a comment:


  • mos87
    replied
    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).

    Leave a comment:


  • mos87
    replied
    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.

    Leave a comment:


  • mos87
    replied
    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.

    Leave a comment:


  • Michael_S
    replied
    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.

    Leave a comment:


  • RahulSundaram
    replied
    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





    Leave a comment:

Working...
X