shawnchen1980
commented
5 years ago To make it clearer, two instances of the team model (ownderId,memberId) do not represent two different teams. And each instance of the team model is not associated with multiple user instances. So the model's name team and the definition of the relation _members_contradicts with its internal definition. It's a big misleading.
It's easy to generate code by lb and that's why it's so attractive at the first glance. But it doesn't simplify the analysis process of the model and relation stuff.
stale[bot]
Each instance of the team model(ownerId, memberId) means that some user(memerId) is a member of some project owned by some other user(ownerId). So both properties are foreign keys to the user model. Such properties should be defined by lb relation rather than lb model because they reflect the relationship between different models. On the other hand,if you follow the example to make team hasMany user, the user model will have another field-memberId, which is useless at all.
I use mysql as the datasource so that the problem becomes obvious. I think the team model here actually expresses a manyToMany relationship between owners and members of projects. A better name I guess is membership or participants, which belongs to user(relation name:owner) and belongs to user(relation name:member). At the same time, user hasMany membership as owner or member.
I know this example is primarily for access control. But constructing an app without considering the underlying db schema is dangerous. I'm just studying loopback for a couple of days. I'm not sure my understanding is right. Please tell me if I misunderstand anything.