feat(wasm-dpp) fix unused tests and tests in Document, DocumentFactory and DataContractFactory - #850
Merged
Merged
Conversation
# Conflicts: # packages/wasm-dpp/lib/test/fixtures/getIdentityUpdateTransitionFixture.js # packages/wasm-dpp/lib/test/fixtures/getInstantAssetLockProofFixture.js # packages/wasm-dpp/test/integration/document/Document.spec.js
# Conflicts: # packages/rs-dpp/src/document/document_factory.rs
# Conflicts: # packages/wasm-dpp/lib/test/fixtures/getIdentityCreateTransitionFixture.js # packages/wasm-dpp/lib/test/fixtures/getIdentityFixture.js
antouhou
changed the title
antouhou
marked this pull request as ready for review
March 27, 2023 07:24
markin-io
approved these changes
Mar 27, 2023
3 tasks
Merged
5 tasks
QuantumExplorer
added a commit
that referenced
this pull request
Sep 4, 2026
…a shared key, #850) Pins grovedb at dashpay/grovedb#850: `PathQuery::merge` (v1) now descends into a key another grafted branch already owns and grafts a limited branch where the two actually diverge, instead of refusing the collision at the first key past the common path; a lone body landing at a merged root keeps the caps on its own branches. Composite document queries (a page plus derived sub-queries under one merged proof) need this: a limited page on `post` merged with a by-id fetch on `post`, or a limited page and a limited lookup under one contract once a cross-contract sub-query lifts the common path to the root, all collide one level above where they diverge. Also carries #849 (flat-subtree drop) from develop. No API change on the platform side. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
QuantumExplorer
added a commit
that referenced
this pull request
Sep 4, 2026
…a shared key, #850) Pins grovedb at dashpay/grovedb#850: `PathQuery::merge` (v1) now descends into a key another grafted branch already owns and grafts a limited branch where the two actually diverge, instead of refusing the collision at the first key past the common path; a lone body landing at a merged root keeps the caps on its own branches. Composite document queries (a page plus derived sub-queries under one merged proof) need this: a limited page on `post` merged with a by-id fetch on `post`, or a limited page and a limited lookup under one contract once a cross-contract sub-query lifts the common path to the root, all collide one level above where they diverge. Also carries #849 (flat-subtree drop) from develop. No API change on the platform side. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
QuantumExplorer
added a commit
that referenced
this pull request
Sep 4, 2026
…ies under one merged proof A feed is a page of posts and, for that page, everything a card renders: the quoted posts, the per-post counts, the authors' profiles, the viewer's own likes. Each is a query whose input is the page, so today a single feed is a burst of dependent round trips. A composite query carries the page and its sub-queries in one request and proves them together: the server materializes the page, derives every sub-query's `IN` clause from it (or from an earlier documents sub-query), and `prove_query_many` merges every component into one proof over one root. Three bound shapes and one unbound one: a by-id join (the source property must be a `refersTo: permanentDocument`, so every derived id resolves and the result is set-equal to the ids), a documents lookup by an indexed property (absence inherent in the range proof; may target another contract; limit required unless a unique index or an indexOnly terminal already bounds it to one row per value), a grouped point-lookup count on a countable index, and a sibling documents query. Derived values are identifiers; the page carries an explicit limit of at most 100 and no cursor. The verifier trusts nothing about the derivation: it bootstraps the page (and any sub-query feeding a later binding) with a subset pass, derives every sub-query with the same builders the server ran, merges the same way, verifies the composition in one authoritative pass, routes the proved entries back to their components (by path, by element kind, and by bound-value membership), and refuses an entry no derivation asked for, a dangling join, or a page that derives different values than the proof covers. A page-only proof from a node ignoring the sub-queries fails closed. Needs grovedb #850 (limited branches graft below a shared key). A count may not share an index path with a documents component: the count reads the value trees the lookup descends past. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
QuantumExplorer
added a commit
that referenced
this pull request
Sep 5, 2026
…below a shared key) (#4597)
5 tasks
QuantumExplorer
added a commit
that referenced
this pull request
Sep 5, 2026
…ies under one merged proof A feed is a page of posts and, for that page, everything a card renders: the quoted posts, the per-post counts, the authors' profiles, the viewer's own likes. Each is a query whose input is the page, so today a single feed is a burst of dependent round trips. A composite query carries the page and its sub-queries in one request and proves them together: the server materializes the page, derives every sub-query's `IN` clause from it (or from an earlier documents sub-query), and `prove_query_many` merges every component into one proof over one root. Three bound shapes and one unbound one: a by-id join (the source property must be a `refersTo: permanentDocument`, so every derived id resolves and the result is set-equal to the ids), a documents lookup by an indexed property (absence inherent in the range proof; may target another contract; limit required unless a unique index or an indexOnly terminal already bounds it to one row per value), a grouped point-lookup count on a countable index, and a sibling documents query. Derived values are identifiers; the page carries an explicit limit of at most 100 and no cursor. The verifier trusts nothing about the derivation: it bootstraps the page (and any sub-query feeding a later binding) with a subset pass, derives every sub-query with the same builders the server ran, merges the same way, verifies the composition in one authoritative pass, routes the proved entries back to their components (by path, by element kind, and by bound-value membership), and refuses an entry no derivation asked for, a dangling join, or a page that derives different values than the proof covers. A page-only proof from a node ignoring the sub-queries fails closed. Needs grovedb #850 (limited branches graft below a shared key). A count may not share an index path with a documents component: the count reads the value trees the lookup descends past. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue being fixed or feature implemented
Some tests for documents and data contract weren't function properly or we failing
What was done?
Fix tests; Fix some bugs in the implementation; Moved all fixtures from js-dpp to wasm-dpp
How Has This Been Tested?
Run tests
Breaking Changes
None
Checklist:
For repository code-owners and collaborators only