Skip to content
This repository was archived by the owner on May 16, 2019. It is now read-only.

Support for suspendable property resolvers #38

Open
jeggy opened this issue Nov 20, 2018 · 2 comments · May be fixed by #52
Open

Support for suspendable property resolvers #38

jeggy opened this issue Nov 20, 2018 · 2 comments · May be fixed by #52

Comments

@jeggy
Copy link
Contributor

jeggy commented Nov 20, 2018

Would be great with suspendable property resolvers. Something like #37. But something that actually works.

I haven't gotten a full overview of how everything in this project works yet, so I failed implementing this. If there is anything I can help out with I would love to.

@giylmi
Copy link

giylmi commented Nov 21, 2018

Would to see this feature as well! So I could use java-dataloader which uses Futures.
The problem is that we can't just call dataloader.dispatchAndJoin in property resolver since the batching won't work.

With suspend resolver we could use await() to solve the problem

@jeggy
Copy link
Contributor Author

jeggy commented Jan 3, 2019

I've been thinking about implementing a dataloader directly into this project.

Haven't figured exactly how to archive it yet, but I'm thinking something like this?

...
data class Tree(val id: String, val parentId: String?)
...
type<Tree> {
    // String - defines the key that will be sent from the [prepare] into [loader]
    // List<Tree> - defines the return type that the [loader] is required to return.
    // the loader is then required to return it in a map format like Map<String, List<Tree>>
    dataProperty<String, List<Tree>>("children") {
        // Step 2: This will only be called once.
        loader { keys: List<String> ->
            keys.map{ id -> id to listOf(Tree("SomeId", id)) }.toMap()
        }
    
        // Step 1: This will be called for each node in the list, or only once if it's not a list
        prepare { parent: Tree -> parent.id }
        
        // Step 3(Optional): This will be called as many times as the prepare did, but now holds the loaded values
        resolve { resolved: List<Tree> -> resolved } // This could maybe process something extra and then return some other type instead of List<Tree>
    }
    ...
}

Please come with any ideas how something like this could look like.

jeggy added a commit to jeggy/KGraphQL that referenced this issue Jan 26, 2019

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@jeggy jeggy linked a pull request Jan 26, 2019 that will close this issue
jeggy added a commit to jeggy/KGraphQL that referenced this issue Feb 2, 2019
jeggy added a commit to jeggy/KGraphQL that referenced this issue Feb 6, 2019

Verified

This commit was signed with the committer’s verified signature.
benelan Ben Elan
jeggy added a commit to jeggy/KGraphQL that referenced this issue Feb 6, 2019

Verified

This commit was signed with the committer’s verified signature.
benelan Ben Elan
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants