Yes there's an abstraction layer and a price to be for that: the more backends
there are, the more it hurts *all* development in that area because all
backends need to be patched whenever something changes. We don't want new
backends just because a DB engine exists, this is a case where less is
In this case, I actually _disagree_ with @pmatilai because I think RPM moves
too slowly as it is, and we can easily accept another backend and have it in
experimental status, like we did for NDB (which is now stable after some
real-world testing).
--
You are receiving this because you are subs
I know we disagree a lot @pmatilai, but in this case I believe your decision
was absolutely correct. SQLite is *far* better tested, has more features, and
will be supported through at least 2050.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
I don't know what that's supposed to mean. The point is, there's absolutely
zero longevity record for MDBX at this point. As repeated multiple times now,
maybe in time that may change. LMDB for its shortcomings was at least backed by
a long-standing organization and widely used, so can be reason
Considering MDBX is forked from LMDB, I don't think that's exactly true in this
case.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/958#issuecomment-860589901__
As I said in an earlier comment, rpm is not in the business of pioneering new
database engines in development. Come back in 10 years for a re-evaluation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm
> Anyway, you say you were "burned by upstream". Was it LMDB's upstream?
> Because if so, this is squarely one of the reasons why we switched to MDBX.
Yes. We were burned by attitude and broken promises from the LMDB developer.
--
You are receiving this because you are subscribed to this thread
I cannot speak for Leonid, but as you said, popular belief is that Red Hat
foots the development bill, so an outsider could consider such a
half-joke/half-offer acceptable. And pretty sure it was _not_ an attempt to
troll anyone.
Anyway, you say you were "burned by upstream". Was it _LMDB's ups
@vorot93 It was definitely in poor taste, and given our experience with the
LMDB upstream, we're pretty wary of having an upstream who wouldn't be
responsive to the larger community of RPM users that would consume MDBX. We
were burned once, and we don't want to be burned again. If someone wants
I'm probably late to the party, but @pmatilai what was your problem with
@erthink's offer?
We at Erigon have successfully switched away from LMDB to MDBX, which has
helped solve numerous issues as [documented
here](https://github.com/ledgerwatch/erigon/wiki/Criteria-for-transitioning-from-Alpha
That is not the kind of upstream we want. Thanks for making that part clear.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/958#issuecomment-601061509
Closed #958.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/958#event-3144622765___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Is anyone willing to make a bet with me that
[MDBX](https://github.com/erthink/libmdbx) (reasonable, no-cheating) will save
half the resources? (probably up to 5-10 times, but I'm not a bookmaker).
$99.99
--
You are receiving this because you are subscribed to this thread.
Reply to this email d
Recent rpm versions have no problem supporting multiple backends and converting
between them on the fly, that's a fairly obvious pre-requisite for ever getting
off BDB in the first place.
And yeah I noticed the mentions of "MithrilDB" development with API and format
considerations and that's qu
> The thing is, the rpmdb is unlike your average database. People expect to be
> able to access it both backwards and forwards in time across chroots,
> containers for builds, software inventory and whatnot. And when that ability
> is taken away (by introducing a new engine, or just an incompati
The thing is, the rpmdb is unlike your average database. People expect to be
able to access it both backwards and forwards in time across chroots,
containers for builds, software inventory and whatnot. And when that ability is
taken away (by introducing a new engine, or just an incompatible engi
> And how about 15 years from now?
IMHO:
- Whatever storage engine was chosen now, this choice will look suboptimal in
15-25 years.
- The right strategy is to be able to choose easily, rather than trying to
choose the best engine "now & forever".
- A good tactic might be to add/replace an exp
And how about 15 years from now? That's the kind of longevity that rpm needs
from the database engines.
It's good to see new potential alternatives emerge. But to set the expectations
straight, rpm is not in the business of pioneering database engines, our main
interest is in technologies that
> I also assume MDBX would be a more responsive upstream to our needs?
Yes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/958#issuecomment-559983635
@leo-yuriev Would you consider getting MDBX packaged up in Fedora? That'd help
us to be able to consider it for rpm upstream and do CI with it...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softwar
@leo-yuriev I think it would be worth considering replacing LMDB with MDBX,
given those improvements. I also assume MDBX would be a more responsive
upstream to our needs?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
http
Ack, useful to know.
That said, what we don't need right now is more experimental backends based on
new engines. In time though, who knows.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-man
@pmatilai, briefly **MDBX support 2 times longer keys than LMDB**.
In details:
- the key size limit depends from the database page size.
- for default (4K) pages MDBX now accepts keys up 1980 bytes (ie slightly less
than half the page size).
- but this value will soon be revised down to be sli
Seeing that this is a fork of LMDB, how's the key size limit? If it's the same
as LMDB then this is not any better for us.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues
MDBX (i.e. [libmdbx](https://github.com/leo-yuriev/libmdbx)) is superior to
LMDB with set of additional features ([the
list](https://github.com/leo-yuriev/libmdbx#improvements-over-lmdb)). For rpmdb
most useful are:
1. Automatic on-the-fly database size control by preset parameters, both
reduct
25 matches
Mail list logo
