# InventoryRef

<table class=".origin_table">
    <tr>
        <td style="text-align: left; border-style: hidden">*class*  of [dascore.core._spool_inventory](`dascore.core._spool_inventory`)</td>
        <td style="text-align: right; border-style: hidden">[source](https://github.com/DASDAE/dascore/blob/dev/dascore/core/_spool_inventory.py#L72-L172)</td>
    </tr>
</table>

:::{.padded_bottom_10pt}

:::{.def_block}


<b>InventoryRef</b>(<br>
    &nbsp;&nbsp;&nbsp;&nbsp;path
,<br>
    &nbsp;&nbsp;&nbsp;&nbsp;blessed
 = False,<br>
)


:::

:::
An inventory a spool has been pointed at but has not read.

Attaching states where the inventory is; the read happens at the
first question only an inventory can answer, and then once. The
holder is shared rather than copied, because a spool copy-constructs
from its parent (`select`, `sort`, `chunk` each return a new one), so
a spool sliced ten ways still reads its inventory a single time and
two views of one parent can never disagree about what it says.

An inventory is an input, not a cache, so it is never re-read behind
the caller's back: a file which changes under a running program is a
new input rather than a stale one, and re-attaching is how the
program says to read it again -- `Spool.attach_inventory()` with no
argument for the one a directory carries, the same path again for
any other. A read which failed is not a read, though, and is tried
again next time: an unreadable inventory is a thing to go and fix,
and holding the failure would mean the fix could not be seen.

## Methods

<table class="table">
  <thead>
    <tr>
            <th scope="col"> Name</th>
            <th scope="col"> Description</th>
    </tr>
  </thead>
  <tbody>
        <tr>
            <td>[resolve](`dascore.core._spool_inventory.InventoryRef.resolve`)</td>
            <td>Return the inventory, reading it if this is the first ask.</td>
        </tr>
  </tbody>
</table>

