-
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
Demo scenario: order history component #1483
Demo scenario: order history component #1483
Comments
@bajtos , this is the acceptance criteria i'm thinking of. Please review, then we can put it up in the description of this ticket. Acceptance Criteria
Note: Suggesting to use MySQL to cover the usage of SQL database. |
Let's keep things simple and store orders in the same database as user profiles. We can always modify the demo later if we decide we want to showcase storing related data in different backing databases.
Let's use the same database as we are using for User profiles. Also AFAIK, there is no free (Lite) plan for hosting MySQL on IBM Cloud. Using MySQL would complicate our deployment.
I think the following two endpoints are enough:
The rest of the acceptance criteria look good to me. I hope it goes without saying that the implementation should come with test coverage and follow the best practices outlined in https://loopback.io/doc/en/lb4/Testing-your-application.html. |
Description / Steps to reproduce / Feature proposal
As part of the e-commerce store demo scenario in #1476, this task is to create the order history component. Data related to user profile, stored in a database.
Taken from comment below
Acceptance Criteria
Model Relation: Customer has a
hasMany
relation with OrderNote: Implementation should come with test coverage and follow the best practices outlined in https://loopback.io/doc/en/lb4/Testing-your-application.html.
The text was updated successfully, but these errors were encountered: