last event support passion list

[Jarsen136]

Thank you for your contribution to the KodaDot Indexer.
👇 _ Let's make a quick check before the contribution.

PR type

• Bugfix
• Feature
• Refactoring

What's new?

• PR closes #<issue_number>
• This PR is required for support passion feed searching in lastEvent resolver nft-gallery#3239

Before submitting Pull Request, please make sure:

• My contribution builds clean without any errors or warnings
• I've merged recent default branch -- main and I've no conflicts
• I've tried to respect high code quality standards
• I've didn't break any original functionality
• I've posted a screenshot of demonstrated change in this PR

Optional

• I've run the indexer and it hasn't failed
• I've changed schema and performed a migration
• I found edge cases

Screenshot

• My contribution is a resolver so I have pic from playground

[vikiival]

3.6

[vikiival]

Thinking if we shouldnt do it otherwise ?
Have you tested that on people that have more items ?

[Jarsen136]

Thinking if we shouldnt do it otherwise ?

It's what we have done with subquery in graphql. Or is there any better solution?

Have you tested that on people that have more items ?

How about 10 address. It still works well and fast.

[vikiival]

Or is there any better solution?

maybe have argument passion: Boolean
and fetch passion that data directly in resolver

How about 10 address. It still works well and fast.

And If you provide like 300 of them wouldn't the query request fail?

[Jarsen136]

Or is there any better solution?

maybe have argument passion: Boolean and fetch passion that data directly in resolver

I'm not sure if it would be better, because the resolver need to request passion list through accountId, and then request lastEvent. It seems costs more time 👀
Please correct me if I understand wrong.

And If you provide like 300 of them wouldn't the query request fail?

In this case, I guess the query would fail : )

[vikiival]

Please correct me if I understand wrong.

Yeah you are right, but I just want to avoid case when person with a lot of buys breaks the query

[Jarsen136]

Yeah you are right, but I just want to avoid case when person with a lot of buys breaks the query

It makes sense.

[Jarsen136]

updated!

---

[vikiival]

I gave also merging rights to @kodadot/autocode so @petersopko can review and merge too

[Jarsen136]

Hey there, pls take a look at this PR if you have time. ❤️ @petersopko

[petersopko]

Hey there, pls take a look at this PR if you have time. ❤️ @petersopko

took a look, tested it out, lgtm