-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove repository index #29
Conversation
1660e8c
to
2c8d2f6
Compare
2c8d2f6
to
d9abd00
Compare
We plan to remove the RepositoryIndex for now and make it fast enough to consult the packs directly. Signed-off-by: Peter Waller <peter.waller@arm.com>
d9abd00
to
08a313f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
I'm thinking we might want to cache the indexes at some point? We will end up reading the same index several times otherwise.
Do you mean cache them in memory? If so, is there a specific operation you had in mind? I was thinking that if some operation needs repeated access to an index it should just retain a loaded PackIndex. |
Cache in memory, yes. Resolving a snapshot name opens and reads all indexes. Opening the pack to extract opens and reads the pack index again. |
At the moment yes, but in the future this will just involve consulting the list of snapshots at the front of the pack. I'm expecting this to be efficient enough to be able to do without the need for a cache.
I think in this case what we coud do is first resolve the total set of packs requested, then consider each pack once, resolving requested snapshots as we go (in the order they appear in their indices). Then reorder those resolved snapshots back to what the user requested. |
I forgot that we're planning to pull the snapshot tags at the front. We'll have to see how that plays out in practice I guess. |
Draft.We plan to remove the RepositoryIndex for now and make it fast enough to
consult the packs directly.
This removes the notion of
update-index
from the UI, and gives us a single source of truth: the pack indices themselves.Depends: #27, #28 (only look at last commit).