-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spike: Resolver for inclusion of related models #2634
Comments
bajtos
changed the title
Spike: resolver for inclusion of related models
Spike: Resolver for inclusion of related models
Mar 22, 2019
This was referenced Mar 22, 2019
Hi @bajtos this._registerHasManyInclusion('todos', todoRepositoryGetter); When I add this code I got the error "_registerHasManyInclusion" it's not defined. Please provide the full function for this _registerHasManyInclusion |
@AnanthGopal this is a spike. The feature is still being worked on and is not implemented or released yet. |
This was referenced Jun 24, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Continue the works started in #2124, leverage the building blocks implemented as an outcome of #2592 and create a detailed proposal for implementing resolver for navigational properties.
Implementation wise, I think we want to end up with the following user experience:
The question is how to implement
_register**Inclusion
APIs and process the registered inclusion handlers infind
/findById
implementations provided byDefaultCrudRepository
. See #1352 (comment) for more details on that.It is important to consider the scenario where we want to fetch multiple source models and include their related models in the result, e.g.
TodoList.find(1, {include: [{relation: 'todos'}]})
. Under the hood, we must avoid SELECT N+1 issue. Inclusion handler must be able to fetch related models for multiple source-model ids in one query (usinginq
operator under the hood). The design proposed in #1352 (comment) is already taking that into account, so does the existing implementation in juggler.Acceptance criteria
examples/todo-list
to show the proposed user experiencepackages/repository
/_SPIKE_.md
) describing the proposal at a high level. Keeping the document in git (instead in GH comments) makes it easier to discuss individual parts of the proposal and keep the proposal versioned.lb4 repository
to generate calls ofthis._registerHasManyInclusion
and friends.The text was updated successfully, but these errors were encountered: