On Tue, May 06, 2025 at 09:00:04PM -0400, Derrick Stolee wrote:
> On 5/6/25 8:51 PM, Derrick Stolee wrote:
> > On 5/6/25 7:09 AM, Patrick Steinhardt wrote:
>
> > > Let's preempt this by renaming the structure to `odb_backend` now
> > > already. This name is agnostic of how exactly objects are stored and
> > > allows us to easily introduce e.g. a `files_odb_backend` and other
> > > specific implementations over time.
> >
> > But here's where I'll get a little nitpicky and say that these are
> > "odb"s not "odb_backend"s.
> >
> > * odb: a single object database. A repo can have multiple, currently
> > only one that is read/write and multiple read-only alternates.
> >
> > * odb backend: an _implementation_ of an object database. This would
> > be the structure that containts a vtable of implementation methods.
> > Each individual 'odb' would point to a single backend describing
> > how to access the data in it.
> >
> > Does that make sense? If we are going through the effort of renaming
> > things, I think it's worth being a little more future-proof here.
Yeah, I agree with you that this can be somewhat confusing indeed. The
problem is that we basically have a database of databases, and that
makes it somewhat awkward to name things.
> And immediately upon sending this message, I went and looked at
> another patch and realized that the rename in Patch 1 would be
> confusing with 'struct object_database' containing a list of
> 'struct odb's.
>
> Perhaps in my head I was thinking that each repository has an
> "object store" which is an abstraction over possibly multiple
> "odb"s which each are interacted with via one "odb backend"
> (and there may be multiple potential odb backends in the future,
> but only one right now).
I don't think that "store" buys us much over "database" -- it's
ultimately the same thing, from my perspective. The only reason why I
decided to drop "store" in favor of "database" is that it allows us to
use the `odb_` prefix in many places, which is nice.
> If we want to keep the 'object_database' name from patch 1 (or
> replace it with 'odb' for brevity) then we might want a different
> name for each sub-odb. Perhaps 'odb_shard'? 'odb_slice'? Do any
> of these sound better?
I don't quite like either of them. "shard" is a bit too close to the
shards we have in ".git/objects/[0-9a-f]{2}" and may thus easily cause
confusion. And "slice" feels a bit weird because... I dunno. I have to
think too much about slices in Golang.
How about `odb_alternate`? That's exactly what this is -- an alternate
part of the object database. We already use this term, and it does make
sense even in the future once we have pluggable ODBs. Honestly, now that
I think about it's kind of the obvious choice. Lots of the parts of the
codebase were already called accordingly.
Patrick
