mirror of
https://github.com/f-droid/fdroidclient.git
synced 2026-04-22 16:01:37 -04:00
5bde27daa8
When preparing a temp database to write to, don't copy all apps/apks. Instead, only copy those _not_ belonging to the repo we are updating. In an ideal world, we'd not even need to copy them, but we need their IDs to be in the temp database so that we don't accidentally use the same auto-generated ID as the main database. This also means that we can drop the check for "does this app exist, and hence should we UPDATE it instead of INSERTing it?" and always just insert it. Then, when copying the temp table back to disk, first delete all apps/apks _belonging to the repo being updated_. Then, copy back the apks/apps we found in the repo. This again improves performance because we no longer need to bopy back and forth data which we know wont change (as evidenced by the fact it belongs to a differen trepo). I don't think this was possible earlier before we did the work to support repo priorities properly. That is because we had a single app which was serviced by several repositories. Now, we have multiple entries in the `fdroid_app` table, for each repo which supports that app.