Resolve an empty store name to the default store

[dimitri-yatsenko]

Fixes #1574.

Why

The bare-@ store forms (<npy@>, <object@>, and the other store codecs) are documented to use the default store, but every insert, fetch, or garbage collection on such a column raised Storage '' is requested but not configured in stores. The declaration keeps the store name as "" so a codec can tell "store requested" from "no store"; Config.get_store_spec resolved the default only for None.

Once such columns can be written, a second problem appears: GarbageCollector compared each reference's recorded store name with the store it collects. Bare-@ references record "", so a collector bound to the default store by name would have counted their files as orphans, and collect(dry_run=False) would have deleted files that existing rows still reference.

What changes

• Config.get_store_spec: an empty store name resolves like None, to stores.default, or to stores.filepath_default for filepath references.
• GarbageCollector._references: a reference whose recorded store name is empty or missing matches the default store.

Tests

• Unit: get_store_spec("") resolves to the default store and, for filepath references, to the filepath default; with no stores.default configured it raises stores.default is not configured.
• Integration (TestBareAtUsesDefaultStore in test_gc.py): an insert into a <npy@> column raises when no default store is configured; a <npy@> column round-trips through the default store; and a destructive collection of the default store by name keeps the row's file and reports it as referenced. Without the gc.py change this test fails because the file is deleted; without either change the four tests of the default-store path fail.
• Full suite: 1145 passed, 14 skipped.

[lum-agilyti]

The default-store resolution and the named-collector fix look right to me, and the destructive GC test pins the second one nicely.

One thing I noticed while reading, which I may be missing context on: before this change, GarbageCollector(schema, store="") failed in the constructor because get_store_spec("") raised. Now it builds (the backend resolves to the default store), but self.store stays "", so in _references neither self.store is None nor (ref_store or self._default_store) == "" matches any reference. If I'm reading it right, collect(dry_run=False) would then treat every stored file in those schemas as an orphan. "" is also what the heading reports as attr.store for a bare-@ column, so it seems like a value a caller could plausibly pass. I haven't run this, it's from reading gc.py and settings.py, so please correct me if something upstream normalizes it.

A smaller question on semantics: bare-@ references record store "" rather than the store they were written to, so they follow whatever stores.default is at read or collect time. Is that intended if stores.default is later re-pointed?

[dimitri-yatsenko]

Thanks, both points were right. Fixed in 52eff8f.

Empty store name in the collector. GarbageCollector(schema, store="") built a collector that matched no references, so a destructive collect would have treated every file in the default store as an orphan. __init__ now treats "" as None, so it is the default collector. A new test runs store="" against live rows and expects no orphans.

Bare-@ references following stores.default. Recording "" would let these references follow the default if it were re-pointed, breaking reads and letting a collector bound to the old store by name delete live files. Codecs now record the resolved store name (new Config.resolve_store_name, which get_store_spec also uses), so each object stays with the store it was written to. Bare @ could not be written before this PR, so no stored metadata has an empty name. Metadata that records no store still means the current default.

New tests check that the metadata records the resolved name, and that after re-pointing stores.default the existing objects still read and a collector bound to the old store keeps them. All three fail without the fix.