CINXE.COM

<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link rel="stylesheet" href="/css/layout.css?1732633144785"> <link rel="stylesheet" href="/css/nav.css?1732633144785"> <link rel="stylesheet" href="/css/style.css?1732633144785"> <link rel="stylesheet" href="/css/prismjs@1.24-themes-prism.css"> <title>IPLD ♦ </title> </head> <body> <header> <div class="sidebar-button" onclick="document.getElementById('sidebar').classList.toggle('sidebar-open')"> <svg xmlns="http://www.w3.org/2000/svg" aria-hidden="true" role="img" viewBox="0 0 448 512" class="icon"> <path fill="currentColor" d="M436 124H12c-6.627 0-12-5.373-12-12V80c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12zm0 160H12c-6.627 0-12-5.373-12-12v-32c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12zm0 160H12c-6.627 0-12-5.373-12-12v-32c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12z"></path> </svg> </div> <a href="/" class="logo">IPLD</a> <aside id=breadcrumbs> <ul> <li><a href="/specs">specs</a></li> <li><a href="/specs/selectors">selectors</a></li> <li><a href="/specs/selectors/fixtures">fixtures</a></li> <li><a href="/specs/selectors/fixtures/selector-fixtures-1/">selector-fixtures-1</a></li> </ul> </aside> </header> <aside id=sidebar> <nav> <ul> <li> <a href="/docs/">Docs</a><ul> <li> <a href="/docs/intro/">Intro</a><ul> <li> <a href="/docs/intro/hello-world/">Hello, World</a></li> <li> <a href="/docs/intro/primer/">The Brief Primer</a></li> <li> <a href="/docs/intro/ecosystem/">InterPlanetary Ecosystem Overview</a></li> <li> <a href="/docs/intro/community/">Finding Community</a></li></ul></li> <li> <a href="/docs/motivation/">Motivation</a><ul> <li> <a href="/docs/motivation/benefits-of-content-addressing/">Benefits of Content Addressing</a></li> <li> <a href="/docs/motivation/data-to-data-structures/">From Data to Data Structures</a></li></ul></li> <li> <a href="/docs/codecs/">Codecs</a><ul> <li> <a href="/docs/codecs/known/">Known Codecs</a><ul> <li> <a href="/docs/codecs/known/dag-cbor/">DAG-CBOR</a></li> <li> <a href="/docs/codecs/known/dag-json/">DAG-JSON</a></li> <li> <a href="/docs/codecs/known/dag-pb/">DAG-PB</a></li></ul></li></ul></li> <li> <a href="/docs/data-model/">Data Model</a><ul> <li> <a href="/docs/data-model/node/">Nodes</a></li> <li> <a href="/docs/data-model/kinds/">Kinds</a></li> <li> <a href="/docs/data-model/pathing/">Pathing</a></li> <li> <a href="/docs/data-model/traversal/">Traversal</a></li></ul></li> <li> <a href="/docs/advanced-data-layouts/">Advanced Data Layouts</a><ul> <li> <a href="/docs/advanced-data-layouts/intro/">Intro to ADLs</a></li> <li> <a href="/docs/advanced-data-layouts/naming/">ADL Naming</a></li> <li> <a href="/docs/advanced-data-layouts/signalling/">Signalling ADLs</a></li> <li> <a href="/docs/advanced-data-layouts/dynamic-loading/">Dynamic Loading</a></li> <li> <a href="/docs/advanced-data-layouts/known/">Known ADLs</a></li></ul></li> <li> <a href="/docs/schemas/">Schemas</a><ul> <li> <a href="/docs/schemas/intro/">Introduction</a><ul> <li> <a href="/docs/schemas/intro/compare/">compare</a></li> <li> <a href="/docs/schemas/intro/goals/">Goals</a></li> <li> <a href="/docs/schemas/intro/feature-summary/">Feature Summary</a></li></ul></li> <li> <a href="/docs/schemas/features/">Features</a><ul> <li> <a href="/docs/schemas/features/typekinds/">Type Kinds</a></li> <li> <a href="/docs/schemas/features/representation-strategies/">Representation Strategies</a></li> <li> <a href="/docs/schemas/features/links/">Links</a></li> <li> <a href="/docs/schemas/features/indicating-adls/">Using ADLs in Schemas</a></li></ul></li> <li> <a href="/docs/schemas/using/">Using Wisely</a><ul> <li> <a href="/docs/schemas/using/authoring-guide/">Authoring Guide</a></li> <li> <a href="/docs/schemas/using/migrations/">Migrations</a></li></ul></li></ul></li> <li> <a href="/docs/synthesis/">Synthesis</a><ul> <li> <a href="/docs/synthesis/gtd/">Getting Things Done</a></li> <li> <a href="/docs/synthesis/building-in-alignment/">Building in Alignment</a></li> <li> <a href="/docs/synthesis/how-ipfs-web-gateways-work/">How IPFS Web Gateways Work</a></li> <li> <a href="/docs/synthesis/encryption/">Working With Encryption</a></li></ul></li></ul></li> <li> <a href="/specs/">Specs</a><ul> <li> <a href="/specs/about/">About the Specifications</a></li> <li> <a href="/specs/codecs/">Codecs</a><ul> <li> <a href="/specs/codecs/dag-cbor/">DAG-CBOR</a><ul> <li> <a href="/specs/codecs/dag-cbor/spec/">Spec</a></li> <li> <a href="/specs/codecs/dag-cbor/fixtures/">DAG-CBOR Test Fixtures</a><ul> <li> <a href="/specs/codecs/dag-cbor/fixtures/cross-codec/">cross-codec</a></li></ul></li></ul></li> <li> <a href="/specs/codecs/dag-cosmos/">DAG-COSMOS</a><ul> <li> <a href="/specs/codecs/dag-cosmos/basic_types/">basic_types</a></li> <li> <a href="/specs/codecs/dag-cosmos/cosmos_state/">cosmos_state</a></li> <li> <a href="/specs/codecs/dag-cosmos/crypto_types/">crypto_types</a></li> <li> <a href="/specs/codecs/dag-cosmos/tendermint_chain/">tendermint_chain</a></li> <li> <a href="/specs/codecs/dag-cosmos/typed_protobuf/">typed_protobuf</a></li></ul></li> <li> <a href="/specs/codecs/dag-eth/">DAG-ETH</a><ul> <li> <a href="/specs/codecs/dag-eth/basic_types/">basic_types</a></li> <li> <a href="/specs/codecs/dag-eth/chain/">chain</a></li> <li> <a href="/specs/codecs/dag-eth/convenience_types/">convenience_types</a></li> <li> <a href="/specs/codecs/dag-eth/state/">state</a></li></ul></li> <li> <a href="/specs/codecs/dag-jose/">DAG-JOSE</a><ul> <li> <a href="/specs/codecs/dag-jose/spec/">Spec</a></li> <li> <a href="/specs/codecs/dag-jose/fixtures/">fixtures</a></li></ul></li> <li> <a href="/specs/codecs/dag-json/">DAG-JSON</a><ul> <li> <a href="/specs/codecs/dag-json/spec/">Spec</a></li> <li> <a href="/specs/codecs/dag-json/fixtures/">DAG-JSON Test Fixtures</a><ul> <li> <a href="/specs/codecs/dag-json/fixtures/cross-codec/">cross-codec</a></li></ul></li></ul></li> <li> <a href="/specs/codecs/dag-pb/">DAG-PB</a><ul> <li> <a href="/specs/codecs/dag-pb/spec/">Spec</a></li> <li> <a href="/specs/codecs/dag-pb/fixtures/">DAG-PB Test Fixtures</a><ul> <li> <a href="/specs/codecs/dag-pb/fixtures/cross-codec/">cross-codec</a></li></ul></li></ul></li></ul></li> <li> <a href="/specs/advanced-data-layouts/">Advanced Data Layouts</a><ul> <li> <a href="/specs/advanced-data-layouts/fbl/">FBL ADL</a><ul> <li> <a href="/specs/advanced-data-layouts/fbl/spec/">spec</a></li></ul></li> <li> <a href="/specs/advanced-data-layouts/hamt/">HAMT ADL</a><ul> <li> <a href="/specs/advanced-data-layouts/hamt/spec/">spec</a></li> <li> <a href="/specs/advanced-data-layouts/hamt/fixture/">HashMap (HAMT) Test Fixtures</a><ul> <li> <a href="/specs/advanced-data-layouts/hamt/fixture/alice-words/">alice-words</a></li></ul></li></ul></li></ul></li> <li> <a href="/specs/schemas/">Schemas</a><ul> <li> <a href="/specs/schemas/prelude/">prelude</a></li></ul></li> <li> <a href="/specs/transport/">Transports</a><ul> <li> <a href="/specs/transport/car/">CAR</a><ul> <li> <a href="/specs/transport/car/carv1/">CARv1 Specification</a></li> <li> <a href="/specs/transport/car/carv2/">CARv2 Specification</a></li> <li> <a href="/specs/transport/car/fixture/">CAR Test Fixtures</a><ul> <li> <a href="/specs/transport/car/fixture/carv1-basic/">carv1-basic</a></li> <li> <a href="/specs/transport/car/fixture/carv2-basic/">carv2-basic</a></li></ul></li></ul></li> <li> <a href="/specs/transport/graphsync/">Graphsync</a><ul> <li> <a href="/specs/transport/graphsync/known_extensions/">known_extensions</a></li></ul></li> <li> <a href="/specs/transport/trustless-pathing/">Trustless Pathing</a><ul> <li> <a href="/specs/transport/trustless-pathing/fixtures/">Trustless Pathing Fixtures</a><ul> <li> <a href="/specs/transport/trustless-pathing/fixtures/unixfs_20m_variety/">unixfs_20m_variety</a></li></ul></li></ul></li></ul></li> <li> <a href="/specs/selectors/">Selectors</a><ul> <li> <a href="/specs/selectors/fixtures/">fixtures</a><ul> <li class="active-page"> <a href="/specs/selectors/fixtures/selector-fixtures-1/">selector-fixtures-1</a></li> <li> <a href="/specs/selectors/fixtures/selector-fixtures-adl/">selector-fixtures-adl</a></li> <li> <a href="/specs/selectors/fixtures/selector-fixtures-recursion/">selector-fixtures-recursion</a></li></ul></li></ul></li> <li> <a href="/specs/patch/">Patch</a><ul> <li> <a href="/specs/patch/fixtures/">IPLD Patch Test Fixtures</a><ul> <li> <a href="/specs/patch/fixtures/fixtures-1/">fixtures-1</a></li></ul></li></ul></li></ul></li> <li> <a href="/libraries/">Libraries</a><ul> <li> <a href="/libraries/golang/">Golang</a></li> <li> <a href="/libraries/javascript/">JavaScript</a></li> <li> <a href="/libraries/python/">Python</a></li> <li> <a href="/libraries/rust/">Rust</a></li></ul></li> <li> <a href="/design/">Design</a><ul> <li> <a href="/design/objectives/">Objectives</a></li> <li> <a href="/design/concepts/">Concepts</a><ul> <li> <a href="/design/concepts/type-theory-glossary/">type-theory-glossary</a></li></ul></li> <li> <a href="/design/libraries/">Libraries</a><ul> <li> <a href="/design/libraries/nodes-and-kinds/">nodes-and-kinds</a></li></ul></li> <li> <a href="/design/tricky-choices/">Tricky Choices</a><ul> <li> <a href="/design/tricky-choices/dag-pb-forms-impl-and-use/">dag-pb-forms-impl-and-use</a></li> <li> <a href="/design/tricky-choices/map-key-domain/">map-key-domain</a></li> <li> <a href="/design/tricky-choices/numeric-domain/">numeric-domain</a></li> <li> <a href="/design/tricky-choices/ordering/">ordering</a></li> <li> <a href="/design/tricky-choices/string-domain/">string-domain</a></li></ul></li> <li> <a href="/design/open-research/">Open Research</a><ul> <li> <a href="/design/open-research/ADL-autoexecution/">ADL autoexecution</a></li></ul></li></ul></li> <li> <a href="/tools/">Tools</a></li> <li> <a href="/glossary/">Glossary</a></li> <li> <a href="/media/">Media</a></li> <li> <a href="/FAQ/">FAQ</a></li></ul> </nav> </aside> <main> <div class=content> <h1>Selector Fixtures 1</h1> This file contains a bunch of fixtures for selectors. These are suitable both as mechanical test fixtures, and as examples for humans. <h3 id="whats-covered" tabindex="-1"><a class="header-anchor" href="#whats-covered">What's covered?</a></h3> All the fixtures in this file are operating on single blocks -- the data can still be a tree (maps, lists, etc), but contains no links. Walking will be exercised; determinism of order will be exercised; and "matched node" vs "reached node" distinctions will be exercised. <h3 id="whats-the-fixture-format" tabindex="-1"><a class="header-anchor" href="#whats-the-fixture-format">What's the fixture format?</a></h3> The fixture data is contained in markdown code blocks. (These should render nicely, and even with syntax highlighting, if you're looking at this in the website.) These code blocks are also tagged with a markdown "comment" which labels them. This is the <a href="https://github.com/warpfork/go-testmark">testmark format</a>; it can be consumed programmatically. (Note that you probably can't see these labels as this page is rendered on the website; go look at the "raw" form of the page, from a git clone of the repo. Otherwise: the headings rendered here say the same things.) Each fixture will have the following hunks of data: <ul> <li><code>data</code> -- this is the "block". It's arbitrary example data. They're all in json (or dag-json) format, for simplicity.</li> <li><code>selector</code> -- this is the selector. Again, as json.</li> <li><code>expect-visit</code> -- these are json lines (one json object on each line) containing description of each node that should be visited, in order.</li> </ul> <h3 id="how-do-i-interpret-this-data" tabindex="-1"><a class="header-anchor" href="#how-do-i-interpret-this-data">How do I interpret this data?</a></h3> To test your selector implementation: <ol> <li>First parse the "data" (this is just a prerequisite; parsing this should already be known to work);</li> <li>Then parse the "selector" (this should succeed -- there are no trick documents here that should fail to parse as selectors);</li> <li>Then evaluate the selector on the data...</li> <li>Each step of the selection process should yield {a path, the node at that path, and whether that point is "matched"}. Each line in the "expect-visit" hunk should correspond to one of these steps.</li> </ol> <h3 id="this-doesnt-have-to-be-json" tabindex="-1"><a class="header-anchor" href="#this-doesnt-have-to-be-json">This doesn't have to be JSON!</a></h3> Remember -- none of these things are locked-in on JSON as a serialization format. You can equally well serialize a Selector declaration as CBOR. You can also apply Selectors on CBOR data just as well as JSON (or apply them on Git data, or anything else there's an IPLD <a href="/docs/codecs/">codec</a> for)! We're just using JSON here because it's convenient and it's human-readable. <hr> <h2 id="fixtures" tabindex="-1"><a class="header-anchor" href="#fixtures">Fixtures</a></h2> <h3 id="matching-a-single-node" tabindex="-1"><a class="header-anchor" href="#matching-a-single-node">matching a single node</a></h3> This test is the simplest hello-world. The data just has a single node, and the selector just matches exactly the node it was applied on. <h4 id="data" tabindex="-1"><a class="header-anchor" href="#data">data</a></h4> <pre class="language-json"><code class="language-json">"basic test"</code></pre> <h4 id="selector" tabindex="-1"><a class="header-anchor" href="#selector">selector</a></h4> <pre class="language-json"><code class="language-json">{ ".": {} }</code></pre> <h4 id="expected-visit-events" tabindex="-1"><a class="header-anchor" href="#expected-visit-events">expected visit events</a></h4> <pre class="language-json"><code class="language-json">{"path": "", "node": {"string": "basic test"}, "matched": true}</code></pre> <hr> <h3 id="matching-a-small-map" tabindex="-1"><a class="header-anchor" href="#matching-a-small-map">matching a small map</a></h3> This test matches on a small map. It doesn't recurse; it just matches one element. Note how we do the expectation data here! If the node is a map or list kind, we say just "null" as the value; this is to avoid making the data oversized and redundant. <h4 id="data-1" tabindex="-1"><a class="header-anchor" href="#data-1">data</a></h4> <pre class="language-json"><code class="language-json">{ "foo": true, "other": {} }</code></pre> <h4 id="selector-1" tabindex="-1"><a class="header-anchor" href="#selector-1">selector</a></h4> <pre class="language-json"><code class="language-json">{ ".": {} }</code></pre> <h4 id="expected-visit-events-1" tabindex="-1"><a class="header-anchor" href="#expected-visit-events-1">expected visit events</a></h4> <pre class="language-json"><code class="language-json">{"path": "", "node": {"map": null}, "matched": true}</code></pre> <hr> <h3 id="exploring-fields" tabindex="-1"><a class="header-anchor" href="#exploring-fields">exploring fields</a></h3> This test takes several steps over a small map. So, it's our first fixture that's actually going to have several entries in the visit expectations list! But, note that it does not touch every entry in the map -- with a "fields" selector, the traverse only touches what's explicitly described. Also notice that this selector traverses the map node during its exploration, but does not match the map node itself -- while it does match the fields. <h4 id="data-2" tabindex="-1"><a class="header-anchor" href="#data-2">data</a></h4> <pre class="language-json"><code class="language-json">{ "bar": false, "foo": true, "some_other": {} }</code></pre> <h4 id="selector-2" tabindex="-1"><a class="header-anchor" href="#selector-2">selector</a></h4> <pre class="language-json"><code class="language-json">{ "f": { "f>": { "foo": { ".": {} }, "bar": { ".": {} } } } }</code></pre> This looks like a mouthful but is pretty simple: <ul> <li>The map with the <code>"f"</code> key is an <code>ExploreFields</code> clause.</li> <li>The <code>"f>"</code> is the <code>ExploreFields.fields</code> value.</li> <li>The two entries in there -- <code>"foo"</code> and <code>"bar"</code> -- are the field names we're saying we want to explore under.</li> <li>The next thing we do after each of those is a <code>Matcher</code> clause.</li> <li>Done!</li> </ul> <h4 id="expected-visit-events-2" tabindex="-1"><a class="header-anchor" href="#expected-visit-events-2">expected visit events</a></h4> <pre class="language-ipldsch"><code class="language-ipldsch">{"path": "", "node": {"map": null}, "matched": false} {"path": "foo", "node": {"bool": true}, "matched": true} {"path": "bar", "node": {"bool": false}, "matched": true}</code></pre> Note how the root node, though it's necessarily been visited, is not "matched". Also note that the order of fields in the <code>ExploreFields</code> clause determined the order of the results! (It dominated the ordering of the data; notice how the data would've had <code>"bar"</code> come first.) <hr> <h3 id="exploring-fields-nested" tabindex="-1"><a class="header-anchor" href="#exploring-fields-nested">exploring fields, nested</a></h3> This test is similar to the previous fixture, but shows how selector clauses can be nested. <h4 id="data-3" tabindex="-1"><a class="header-anchor" href="#data-3">data</a></h4> <pre class="language-json"><code class="language-json">{ "nested": { "newt": 8 }, "foo": true, "bar": 5 }</code></pre> <h4 id="selector-3" tabindex="-1"><a class="header-anchor" href="#selector-3">selector</a></h4> <pre class="language-json"><code class="language-json">{ "f": { "f>": { "foo": { ".": {} }, "nested": { "f": { "f>": { "newt": { ".": {} } } } } } } }</code></pre> That got deeper! If it looks daunting, look back up to the prior fixture, though (and its explainer). It's the same stuff, just more of it. <h4 id="expected-visit-events-3" tabindex="-1"><a class="header-anchor" href="#expected-visit-events-3">expected visit events</a></h4> <pre class="language-json"><code class="language-json">{"path": "", "node": {"map": null}, "matched": false} {"path": "foo", "node": {"bool": true}, "matched": true} {"path": "nested", "node": {"map": null}, "matched": false} {"path": "nested/newt", "node": {"int": 8}, "matched": true}</code></pre> <hr> <h3 id="explore-by-index" tabindex="-1"><a class="header-anchor" href="#explore-by-index">explore by index</a></h3> Exploration can also be done over indexes of lists. This is very similar to using <code>ExploreFields</code>, but uses integers instead of strings, because it's working with lists, rather than maps. <h4 id="data-4" tabindex="-1"><a class="header-anchor" href="#data-4">data</a></h4> <pre class="language-json"><code class="language-json">[ "0", "1", "2" ]</code></pre> <h4 id="selector-4" tabindex="-1"><a class="header-anchor" href="#selector-4">selector</a></h4> <pre class="language-json"><code class="language-json">{ "i": { "i": 1, ">": { ".": {} } } }</code></pre> <h4 id="expected-visit-events-4" tabindex="-1"><a class="header-anchor" href="#expected-visit-events-4">expected visit events</a></h4> <pre class="language-json"><code class="language-json">{"path": "", "node": {"list": null}, "matched": false} {"path": "1", "node": {"string": "1"}, "matched": true}</code></pre> <hr> <h3 id="exploring-a-range" tabindex="-1"><a class="header-anchor" href="#exploring-a-range">exploring a range</a></h3> Another form of selector clause can specify ranges over lists. This is more compact to declare than listing each element you want out of a list, if there's several things you want in a row. <h4 id="data-5" tabindex="-1"><a class="header-anchor" href="#data-5">data</a></h4> <pre class="language-json"><code class="language-json">[ 0, null, "s", {} ]</code></pre> <h4 id="selector-5" tabindex="-1"><a class="header-anchor" href="#selector-5">selector</a></h4> <pre class="language-json"><code class="language-json">{ "r": { "^": 1, "$": 3, ">": { ".": {} } } }</code></pre> <h4 id="expected-visit-events-5" tabindex="-1"><a class="header-anchor" href="#expected-visit-events-5">expected visit events</a></h4> <pre class="language-json"><code class="language-json">{"path": "", "node": {"list": null}, "matched": false} {"path": "1", "node": {"null": null}, "matched": true} {"path": "2", "node": {"string": "s"}, "matched": true}</code></pre> <hr> <h3 id="slice-matching" tabindex="-1"><a class="header-anchor" href="#slice-matching">slice matching</a></h3> Matching a node that is a string or bytes can match a subset of the string or bytes. This is primarily helpful in the case of an ADL that reifies a complex representation into a simplified single string or bytes node, such as one that represents a multi-block bytes node as a single bytes node. <h4 id="data-6" tabindex="-1"><a class="header-anchor" href="#data-6">data</a></h4> <pre class="language-json"><code class="language-json">"a long string that we want to match a subset of"</code></pre> <h4 id="selector-6" tabindex="-1"><a class="header-anchor" href="#selector-6">selector</a></h4> <pre class="language-json"><code class="language-json">{ ".": { "subset": { "[": 30, "]": 44 } } }</code></pre> <h4 id="expected-visit-events-6" tabindex="-1"><a class="header-anchor" href="#expected-visit-events-6">expected visit events</a></h4> <pre class="language-ipldsch"><code class="language-ipldsch">{"path": "", "node": {"string": "match a subset"}, "matched": true}</code></pre> <hr> <h3 id="slice-matching-with-negative-indexes-and-extreme-values" tabindex="-1"><a class="header-anchor" href="#slice-matching-with-negative-indexes-and-extreme-values">slice matching with negative indexes and extreme values</a></h3> Negative indexes for both "from" and "to" can be used to count from the end of the string or bytes node. The "to" index can be greater than the length of the string or bytes node, in which case it is treated as the length of the string or bytes node. After adjusting "from" and "to" values to the known length of the string or bytes node, the following rules are applied: <ul> <li>Overflow of "to" is allowed and is interpreted as the end of the slice. This allows for a simple way to specify a slice from a particular index to the end of the slice, without needing to know the length of the slice.</li> <li>Underflow of "from" is allowed (which can only occur when "from" is a negative that is greater than the length of the slice), and is interpreted as the beginning of the slice.</li> <li>Overflow of "from" and underflow of "to" are not adjusted or reinterpreted. These conditions will cause the selector to fail to match anything.</li> <li>Where the from:to range fails to match within the byte range of the node, (e.g. where they select a range beyond the end of the node), or where they resolve to a negative, or zero-length range (from>=to), the selector will fail to match. However, in the case where from==to, the selector will match, but the matched node will be an empty string or bytes.</li> </ul> <h4 id="data-7" tabindex="-1"><a class="header-anchor" href="#data-7">data</a></h4> <pre class="language-json"><code class="language-json">"a long string that we want to match a subset of"</code></pre> <h4 id="selector-7" tabindex="-1"><a class="header-anchor" href="#selector-7">selector</a></h4> This selector uses the max signed 64-bit integer as the "to" index as a way to specify the end of the string or bytes node. <pre class="language-json"><code class="language-json">{ ".": { "subset": { "[": -9, "]": 9223372036854775807 } } }</code></pre> <h4 id="expected-visit-events-7" tabindex="-1"><a class="header-anchor" href="#expected-visit-events-7">expected visit events</a></h4> <pre class="language-ipldsch"><code class="language-ipldsch">{"path": "", "node": {"string": "subset of"}, "matched": true}</code></pre> <hr> <h3 id="hello-recursion" tabindex="-1"><a class="header-anchor" href="#hello-recursion">hello recursion!</a></h3> Selectors have a recursion clause! (Terrifying, right?) More selector clauses can be placed inside the recursion clause... and then, eventually, a recursion stop clause, which will cause the selection process to jump back to the recursion start marker. This recursion uses an <code>ExploreAll</code> clause, which is sort of like a wildcard match. The recursion clause then turns that single-level wildcard match into a full recursive graph walk! Recursive selectors have a depth limit. On this data, we'll reach the depth limit before we explore all of the data, so notice how the expectation list for visits is relatively short. Note that there's no actual matcher clause anywhere in this selector. That means this selector will still explore and visit a lot of nodes, but none of them are considered to "match". <h4 id="data-8" tabindex="-1"><a class="header-anchor" href="#data-8">data</a></h4> <pre class="language-json"><code class="language-json">[ { "one": [ { "two": [ 3 ] } ] } ]</code></pre> <h4 id="selector-8" tabindex="-1"><a class="header-anchor" href="#selector-8">selector</a></h4> <pre class="language-json"><code class="language-json">{ "R": { "l": { "depth": 4 }, ":>": { "a": { ">": { "@": {} } } } } }</code></pre> <ul> <li><code>"l"</code> is the <code>limit</code> specifier for the recursion clause.</li> <li><code>":>"</code> is the selector clause that gets applied again at each level of recursion.</li> <li><code>"@"</code> is the recursion edge.</li> </ul> <h4 id="expected-visit-events-8" tabindex="-1"><a class="header-anchor" href="#expected-visit-events-8">expected visit events</a></h4> <pre class="language-json"><code class="language-json">{"path": "", "node": {"list": null}, "matched": false} {"path": "0", "node": {"map": null}, "matched": false} {"path": "0/one", "node": {"list": null}, "matched": false} {"path": "0/one/0", "node": {"map": null}, "matched": false}</code></pre> </div> </main> </body> </html>