Getting the parent of a child

[Szegoo]

Introduces a new storage structure that keeps track of the parent of a child.

This is required for the new query for getting the parent of a child.

Closes: #12

[Szegoo]

From my understanding, there is no way at the moment to iterate over a Mapping therefore I introduced a new mapping that will keep track of the parents of children. Also, would it be useful to track parents of pending children?

@Maar-io @ilionic

[Maar-io]

@bobo-k2 can you please take a look and comment

[Maar-io]

We discussed previously that it is hard to track parent NFT, but in case of nesting, the parent-NFT-address is the owner of the child NFT.
And childNFT can have only one parent

[bobo-k2]

I like the idea, because this is the feature I am missing from current implementation. I agree with @Maar-io. Calling add_chilld is called on parent and you code will update children_parent mapping on parent. Also, please add some tests.

[Szegoo]

@Maar-io @bobo-k2 It seems like calling any query from the query.js file in the integration tests results in the following error:

Error: the object {
  "issue": "OUTPUT_IS_NULL"
} was thrown, throw an Error :)

Should I test the new query with an integration test, seems like we are not testing any other queries.

[boyswan]

@Maar-io @bobo-k2 It seems like calling any query from the query.js file in the integration tests results in the following error:

Error: the object {
  "issue": "OUTPUT_IS_NULL"
} was thrown, throw an Error :)

Should I test the new query with an integration test, seems like we are not testing any other queries.

Do you have an example of a query being called?

[Szegoo]

Do you have an example of a query being called?

@boyswan You mean do I have an example of the get parent query being called, or? For me calling any query in the integration test results in the above-mentioned error. I am not sure if others are facing the same problem. This is the way I make the query:

// code inside the nesting integration test.
// -- snip --
const _ = await child.query.getParentOfChild([child.address, { u64: 1}]);
// ^^^^ Making this call results in an error.
// -- snip --

[bobo-k2]

"OUT

@Szegoo Mario and I debugged similar issue last week. Maybe I can help to find root cause of the problem
Open rmrk-ink/node_modules/@727-ventures/typechain-types/dist/src/query.js and set breakpoint in line 203

Run test in debug mode and when breakpoint is reached in debug console type something like (I am writing this from top of my head so It may not work at first)
console.log(result.asErr.registry.findMetaError(result.asErr.asModule);

[boyswan]

I did some digging and it seems like the issue lies with how the query functions call their storage (was using MintingRef as a way to call internal storage instead of directly accessing it).

It looks like this behaviour has broken since ink 4.0, which will require some changes to how the Query trait works. We can make a separate issue/PR for this, as it's out of the scope of this feature!

[Szegoo]

I've created a separate issue for this: #64

[Maar-io]

you get OUTPUT_IS_NULL when your contract crashes.

The way to see what was the error code is to make breakpoint on the line you posted and check something like
const mod = dispatchError.asModule;
const error = dispatchError.registry.findMetaError(mod);

[Szegoo]

After running in debug mode and some logging I got the following error message:

A call tried to invoke a contract that is flagged as non-reentrant.

https://github.com/paritytech/substrate/blob/3f8dc9ed594fdba455d0bf6780768e7176188514/frame/contracts/src/lib.rs#L829-L832
Seems to me that @boyswan was correct.

[boyswan]

Ahh of course - makes total sense now! So all we need to do is allow reentrancy for these calls. For example:

let parent_collection = PSP34Ref::owner_of_builder(&child_collection, child_id)
    .call_flags(ink::env::CallFlags::default().set_allow_reentry(true))
    .try_invoke();

[Szegoo]

Oh, I got a bit confused, but I understand now :)

[boyswan]

With clone fix, LGTM

[Maar-io]

LGTM