odb: fix ambiguous remote resolution

Related : https://github.com/iterative/studio-support/issues/57

1. Ambiguous behavior: For given script:

#!/bin/bash

set -exu
pushd $TMPDIR

wsp=test_wspace
rep=test_repo

rm -rf $wsp && mkdir $wsp && pushd $wsp
main=$(pwd)

mkdir $rep && pushd $rep

git init 
dvc init

echo "data" > data
echo "data2" > data2

dvc add data data2

echo "  remote: myremote" >> data2.dvc
dvc remote add myremote $main/storage

git add -A
git commit -am "initial"

dvc push -r myremote
rm -rf data data2 .dvc/cache

dvc pull

in fetch

we will get three “different” odb. (None, Local#1, and Local#2). This is happening due to two things: one is that we don’t evaluate “no” remote to our default remote, which, for consistency, we probably should. Another, the bigger problem is that two odb’s are never equal: https://github.com/iterative/dvc-objects/issues/134 While it might not be a big issue for us (yet), Studio might be impacted considerably by it, as we are creating separate remotes for each output. Even though we should use one.

It seems that it’s also related to https://github.com/iterative/dvc-objects/issues/4 - with odb caching we could probably also avoid spawning new odb’s.

cc @Suor

[Suor]

The suspicious even technically part for me is that ObjectDB.__eq__ does not correspond to ObjectDB.__hash__. The latter is quite strait-forward (self.fs.protocol, self.path).

These two are supposed to have a matching logic, as I understand.

[skshetry]

Instantiating ODB does not involve anything other than simple init, and the underlying filesystems are already cached. I did not expect that to be slow.

Is there a use case where this behavior is expected? If the underlying fs are cached, why not cache this too?

Why cache if you don’t need to? In fsspec filesystems, there may be state/sessions/client that need to be reused/reopened so caching helps.

For ODB, it’s not necessary, and caching comes with it’s own set of problems.