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

[LB-Next] Support of Relation for Repository and ModelDefinition #419

Closed
9 tasks
dhmlau opened this issue Jun 30, 2017 · 7 comments
Closed
9 tasks

[LB-Next] Support of Relation for Repository and ModelDefinition #419

dhmlau opened this issue Jun 30, 2017 · 7 comments

Comments

@dhmlau
Copy link
Member

dhmlau commented Jun 30, 2017

Description/Steps to reproduce

For example, Customer and Order has the belongsTo relation. When customerId was given, it becomes the filter for the Order repository. It implies that Order repository is not a free form repository but is constrained by customerID=xxx.

  • When doing CRUD operation, make sure this constraint is honoured.
  • Currently, we are using primary key/foreign key for the relationship. In LB Next, we should allow people to use any properties.

In LB3, we support the following types of model relation:

  • BelongsTo
  • HasOne
  • HasMany
  • HasManyThrough
  • HasAndBelongsToMany
  • Polymorphic
  • EmbedsOne
  • EmbedsMany
  • ReferencesMany

Coming from discussion with @raymondfeng

related to #420

BLOCKED BY

@dhmlau dhmlau assigned dhmlau and unassigned dhmlau Jun 30, 2017
@dhmlau dhmlau added the apex label Jun 30, 2017
@dhmlau dhmlau changed the title Support of Relation for Repository [LB-Next] Support of Relation for Repository Jun 30, 2017
@jonathan-casarrubias
Copy link

Cool...I will keep an eye on this thread

@dhmlau dhmlau changed the title [LB-Next] Support of Relation for Repository [LB-Next] Support of Relation for Repository and ModelDefinition Jun 30, 2017
@kjdelisle kjdelisle added team-apex and removed apex labels Jul 5, 2017
@dhmlau dhmlau added the epic label Jul 5, 2017
@kjdelisle
Copy link
Contributor

@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:

import {Table, Column, Model, HasMany} from 'sequelize-typescript';
 
@Table
class Person extends Model<Person> {
 
  @Column
  name: string;
 
  @Column
  birthday: Date;
 
  @HasMany(() => Hobby)
  hobbies: Hobby[];
}

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?

@kjdelisle
Copy link
Contributor

@raymondfeng bump

@kjdelisle
Copy link
Contributor

cc @bajtos

@jonathan-casarrubias
Copy link

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

@bajtos bajtos added the non-MVP label Dec 15, 2017
@arash01
Copy link
Contributor

arash01 commented Jan 19, 2018

I've created a new issue #812 and just realised it's duplicated.

@dhmlau
Copy link
Member Author

dhmlau commented Feb 26, 2018

Closing this in favor of #995

@bajtos bajtos closed this as completed May 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants