-
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
[LB-Next] Support of Relation for Repository and ModelDefinition #419
Comments
Cool...I will keep an eye on this thread |
@raymondfeng I'm not certain how the relation decorators fit into the loopback-next story; if we want to allow developers to mount their own ORMs and frameworks for retrieving data, there's a good chance that they'll have their own way of defining schemas for those datasources. Using https://www.npmjs.com/package/sequelize-typescript as an example:
Sequelize (the TypeScript version in particular) is leveraging its own idea of what these relations mean. If we build this ourselves, will it only be meant for the legacy-juggler-bridge? If so, aren't users still expected to define their relations in JSON, rather than use annotations? |
@raymondfeng bump |
cc @bajtos |
I would just like to add, we need a way to discover models and relationships, not sure if this will be part of the open-api spec, else we need to somehow discover these relationships in order to auto-generate SDKs and it is imperative to build platforms on top of LBN |
I've created a new issue #812 and just realised it's duplicated. |
Closing this in favor of #995 |
Description/Steps to reproduce
For example,
Customer
andOrder
has thebelongsTo
relation. WhencustomerId
was given, it becomes the filter for theOrder
repository. It implies thatOrder
repository is not a free form repository but is constrained bycustomerID=xxx
.In LB3, we support the following types of model relation:
Coming from discussion with @raymondfeng
related to #420
BLOCKED BY
The text was updated successfully, but these errors were encountered: