Future of RpmDB

[ffesti]

With the switch to the new RpmDB backends (sqlite and ndb) the overall structure of the database was basically untouched - mainly as they still provide the same API.
The databases are just a pile of rpm headers with some indexes/tables allowing to find the ones of interest more quickly. But almost all operation need to load the full header to get to the actual data. With the read-only BDB back end to stay with us for years to come we are unlikely to get rid of this structure any time soon.

In a perfect world the RpmDB would be more database like that allows running queries that only returns the relevant data. One way to get there may be putting a facade in front of the current RpmDB that provides an API that does not return headers. The implementation for the current back ends could just load the headers and pass the data snippets on. New or improved back ends then could start doing smarter things.

The API could return objects similar to the rpmtd and rpmds`data types. In addition to the tag or dependency entries they would have a references to the packages each entry belongs to. The transaction check could then step by step be moved to this new API. After that the newer back ends could adjust their internal structure and make use of the new API directly.

Details still to be figured out.