Re: [PATCH v3 00/17] object-store: carve out the object database subsystem

[Toon Claes <toon@iotcl.com>]

Patrick Steinhardt <ps@pks.im> writes:

> Hi,
>
> this patch series refactors the object store subsystem to become more
> self-contained by getting rid of `the_repository`. Instead of passing in
> the repository explicitly, we start to pass in the object store itself,
> which is in contrast to many other refactorings we did, but in line with
> what we did for the ref store, as well.
>
> This series also starts to properly scope functions to the carved out
> object database subsystem, which requires a bit of shuffling. This
> allows us to have a short-and-sweet `odb_` prefix for functions and
> prepares us for a future with pluggable object backends.
>
> The series is structured as follows:
>
>   - Patches 1 to 3 rename `struct object_store` and `struct
>     object_directory` as well as the code files.
>
>   - Patches 4 to 12 refactor "odb.c" to get rid of `the_repository`.
>
>   - Patches 13 to 17 adjust the name of remaining functions so that they
>     can be clearly attributed to the ODB. I'm happy to kick these
>     patches out of this series and resend them at a later point in case
>     they create too much turmoil.
>
> This series is built on top of 6f84262c44a (The eleventh batch,
> 2025-05-05) with ps/object-store-cleanup at 8a9e27be821 (object-store:
> drop `repo_has_object_file()`, 2025-04-29) merged into it. There are a
> couple of trivial conflicts when merged with "seen", I have appended the
> merge conflict resolution as a patch at the end of this mail.
>
> Changes in v2:
>   - Fix for a copy-and-pasted commit message.
>   - Rename `struct odb_backend` to `struct odb_alternate`. I'm happy to
>     revert to the previous name if we ultimately think it's the better
>     suited one.
>   - A couple of fixes to move changes into the correct commit. `git
>     rebase -x 'meson compile -C build'` is now clean.
>   - I _didn't_ back out the rename to "odb.{c,h}". Junio has already
>     fixed the fallout, so it's probably more work for him to kick it out
>     again than to just leave it in.
>   - Link to v1: https://lore.kernel.org/r/20250506-pks-object-store-wo-the-repository-v1-0-c05b82e7b126@pks.im
>
> Changes in v3:
>   - Polishing for some comments and commit messages.
>   - Link to v2: https://lore.kernel.org/r/20250509-pks-object-store-wo-the-repository-v2-0-103f59bf8e28@pks.im
>
> Thanks!
>
> Patrick

The range-diff looks good, and I've got no further comments.

Only one small question though, what's the point of the compatibility
layer in the last 5(-ish) commits? I mean if we add temp wrappers for
other topics in flight, then when/how do we convert that new code to
stop using the wrappers? Won't we remain having issues because there's
always something in flight?

Cheers,
-- Toon