Skip to content
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

Relational Controllers #1758

Closed
virkt25 opened this issue Sep 25, 2018 · 3 comments
Closed

Relational Controllers #1758

virkt25 opened this issue Sep 25, 2018 · 3 comments
Labels
needs discussion Relations Model relations (has many, etc.) stale

Comments

@virkt25
Copy link
Contributor

virkt25 commented Sep 25, 2018

Description / Steps to reproduce / Feature proposal

Based on loopbackio/loopback4-example-shopping#12 (comment)

I am proposing we eventually add support to our existing relational controllers for manipulating individual related models.

Ex:

/users/{userId}/orders/{orderId}

So this in its current form is not all that helpful as one would argue being able to directly manipulate the model using /orders/{orderId} as we don't have referential integrity (#1718) yet ... but once we do, this can help ensure that only users with access to an order are the ones manipulating it.

This could also just be solved using authorization and may not be needed.

The purpose of this issue is to drive a discussion to figure out if this is needed or not.

@bajtos
Copy link
Member

bajtos commented Feb 4, 2019

Cross-posting loopbackio/loopback4-example-shopping#12 (comment)

We should probably introduce singular controllers for these operations where the orderId is known.

/users/{userId}/orders/{orderId}

We have discussed this in the past, when implementing "hasMany" relation. Updating a single model via relation endpoint does not make much sense. Once you know the id of the target model (orderId), you can update the model directly via non-relation API (PATCH /orders/{orderId}).

The endpoint /users/{userId}/orders/{orderId} would make sense if we were using composite primary keys (e.g. an order is identified by (userId, orderId), think of how GitHub repositories are identified), but our current implementation does not support composite keys AFAIK.


Personally, I think we have more pressing issues to deal with at the moment. I am proposing to put this story on hold for now.

@dhmlau @raymondfeng @strongloop/sq-lb-apex thoughts?

@stale
Copy link

stale bot commented Jan 30, 2020

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

@stale stale bot added the stale label Jan 30, 2020
@stale
Copy link

stale bot commented Feb 29, 2020

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

@stale stale bot closed this as completed Feb 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs discussion Relations Model relations (has many, etc.) stale
Projects
None yet
Development

No branches or pull requests

4 participants