-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Schema Management
-
Storage Engines
-
StorEng - Defined Pipeline
When a tiered storage btree is created, a metadata "file:" entry is created (in addition to other entries), and over time, "object:" entries are created. Basically every flush_tier operation effectively transitions a "file:" entry to an "object:" entry, and creates a new "file:" entry.
But - unlike the non-tiered world where a table: and a file: have a similar relationship and you can open a cursor on either a table: or a file: and get sensible results - you cannot (or maybe should not) open a tiered file: cursor and get something sensible. The easiest way to explain is that the tiered "file:" does not have a checkpoint (or maybe it still has the checkpoint when the file: was originally created. Its checkpoint is not updated, rather the "tiered:" entry is the root of the "whole" btree and where all of its checkpoints are kept.
Possibly a better solution is to make that .wtobj file on disk into an "object:" in the metadata, and have a flag that says it is on disk. If that doesn't suit maybe "wtobj:" or "fileobject:". Otherwise I think we'll be open to weird bugs and/or we'll need strange workarounds.