Skip to content
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

build 'discovery' ODB with auto-consistency for on-disk files #266

Closed
5 tasks done
Byron opened this issue Nov 29, 2021 · 0 comments
Closed
5 tasks done

build 'discovery' ODB with auto-consistency for on-disk files #266

Byron opened this issue Nov 29, 2021 · 0 comments

Comments

@Byron
Copy link
Member

Byron commented Nov 29, 2021

The DB spiked in the discovery has all strengths and seemingly no weaknesses (except for complexity). Let's build it to be able to automatically adapt to changes on disk and to handle server loads efficiently.

The radicle-link ODB shows how a fully sync ODB can look like, and maybe the initial design can be simplified now that it's clear that fully Sync is very fast, too.

Or said differently, it appears that thread-local caches can be used but they probably only make sense for object buffers and pack-caches, less for accelerating object access.

Ideally, a quick-version can be drafted to have benchmark results quickly to even see if the path is right.

What I wish for is more dynamic handling of open file handles, ideally there is a trigger to release unused ones, and generally have a way of handling file limits somewhat gracefully (at least on server/caller level).

Tasks

  • Refactor Find traits #267
  • PoC of new ODB design #273
  • docs
  • make the above production ready
    • tests for parallel pack creation with changes made to the disk state while a pack is being created
    • auto-refresh of disk-state when packs are merged, new packs are added.
  • delete odb-design experiment
Byron added a commit that referenced this issue Nov 30, 2021
The plan is to separate pack location entirely from Object and put
the location specific functions into a separate trait.
Byron added a commit that referenced this issue Nov 30, 2021
This is typed data baked by a slice for conversion into parsed ObjectRef's
for example.

This is usually the result of a `Find` operation on an object database.
Byron added a commit that referenced this issue Nov 30, 2021
It's meant for the next generation of object db handles which keep a
local cache of all the details of the actual object database.
Byron added a commit that referenced this issue Nov 30, 2021
… alter git_odb::Find trait (#266)

This will break a lot, but has to happen to prepare these traits for the
next generation of object databases.
Byron added a commit that referenced this issue Dec 1, 2021
The plan is to separate pack location entirely from Object and put
the location specific functions into a separate trait.
Byron added a commit that referenced this issue Dec 1, 2021
This is typed data baked by a slice for conversion into parsed ObjectRef's
for example.

This is usually the result of a `Find` operation on an object database.
Byron added a commit that referenced this issue Dec 1, 2021
It's meant for the next generation of object db handles which keep a
local cache of all the details of the actual object database.
Byron added a commit that referenced this issue Dec 1, 2021
… alter git_odb::Find trait (#266)

This will break a lot, but has to happen to prepare these traits for the
next generation of object databases.
Byron added a commit that referenced this issue Dec 1, 2021
Byron added a commit that referenced this issue Dec 1, 2021
With the new architecture this can be an implementation detail without
forcing it to be Sync.
Byron added a commit that referenced this issue Dec 2, 2021
The plan is to separate pack location entirely from Object and put
the location specific functions into a separate trait.
Byron added a commit that referenced this issue Dec 2, 2021
This is typed data baked by a slice for conversion into parsed ObjectRef's
for example.

This is usually the result of a `Find` operation on an object database.
Byron added a commit that referenced this issue Dec 2, 2021
It's meant for the next generation of object db handles which keep a
local cache of all the details of the actual object database.
Byron added a commit that referenced this issue Dec 2, 2021
… alter git_odb::Find trait (#266)

This will break a lot, but has to happen to prepare these traits for the
next generation of object databases.
Byron added a commit that referenced this issue Dec 2, 2021
Byron added a commit that referenced this issue Dec 2, 2021
With the new architecture this can be an implementation detail without
forcing it to be Sync.
Byron added a commit that referenced this issue Dec 2, 2021
Borrow is the manual form, Deref has allows for more automatic use
and more idiomatic looking code.
Byron added a commit that referenced this issue Dec 2, 2021
For completeness in case of single-threaded operations
Byron added a commit that referenced this issue Dec 2, 2021
Byron added a commit that referenced this issue Dec 2, 2021
Byron added a commit that referenced this issue Dec 2, 2021
It could easily be general over all kinds of store as long as there
is support for pack-caches, which might be helpful later for the 'final'
store type.

Ideally, this one now shows how to do it.
Byron added a commit that referenced this issue Dec 3, 2021
The plan is to separate pack location entirely from Object and put
the location specific functions into a separate trait.
Byron added a commit that referenced this issue Dec 3, 2021
This is typed data baked by a slice for conversion into parsed ObjectRef's
for example.

This is usually the result of a `Find` operation on an object database.
Byron added a commit that referenced this issue Dec 18, 2021
It's a bit tricky to use the right kind of handle and transform the
Rc<Store> back into an Arc<Store>, but it works.
Byron added a commit that referenced this issue Dec 18, 2021
Byron added a commit that referenced this issue Dec 18, 2021
Byron added a commit that referenced this issue Dec 18, 2021
Byron added a commit that referenced this issue Dec 18, 2021
Byron added a commit that referenced this issue Dec 18, 2021
Byron added a commit that referenced this issue Dec 18, 2021
Byron added a commit that referenced this issue Dec 19, 2021
Byron added a commit that referenced this issue Dec 19, 2021
Byron added a commit that referenced this issue Dec 19, 2021
Byron added a commit that referenced this issue Dec 19, 2021
Byron added a commit that referenced this issue Dec 19, 2021
Byron added a commit that referenced this issue Dec 19, 2021
The latter needs the notion of the index not existing, and shouldn't
fetch it by default or else each sanbox run fetches the entire index.
Byron added a commit that referenced this issue Dec 19, 2021
It now assumes that the crates-index must exist, which migth not always
be the case and rightfully so. Now we wrap it to get back to the
original behavior.
Byron added a commit that referenced this issue Dec 19, 2021
Byron added a commit that referenced this issue Dec 19, 2021
Byron added a commit that referenced this issue Dec 19, 2021
This works by bypassing the central index, which doesn't know about the
garbaged indices anymore, to obtain the indices directly.
Byron added a commit that referenced this issue Dec 19, 2021
@Byron Byron closed this as completed Dec 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant