joshalexis / aninotes-clean-architecture Goto Github PK

In the migration guide for CrocoachDB, in the section of Migration Overview talks about the schema design best practices, one of the topics is the definition of the primary key and says that the sequentials keys should be avoided due performance issues. In this case, it will be necessary to review the current database schema in order to do correctly the migration.

To do this, it will be necessary:

• Create and crocoachdb account and create and app to know how to work with another type of primary key
• Modify the current prima.schema for crocoachDB

In the endpoint /pixiv?page=1&size=10 returns a Bad Request:

{
    "statusCode": 400,
    "message": "Validation failed (numeric string is expected)",
    "error": "Bad Request"
}

The query params are number but it keeps returning a Bad Request response.

See in notion https://www.notion.so/Task-b048cdf1d5694388a7f222ca86107058

See in notion https://www.notion.so/Task-acca6c98c2d94dc5a6ab76df61b55aae

To implement tag assignment, it's required that in each pixiv item has the information of the related tags. The data will be:

• ID of Pixiv Tag record
• Tag's name

Add in:

• Get pixiv by id
• Get pixiv by idPixiv
• Get pixiv list

It is required to add validation schemas before proceed with the test database testing.

• Create Pixiv Schema
• Update Pixiv Schema
• Tests for schemas

See details on Notion task item.

See details on Notion tasks item.

Due to the case of a pixiv artist can create works of suggestive topic and taking into consideration the creation of users module, is
required to filter these artists based on the user's configuration. Also, a new field will be added to save an example of the work of the artist, this example will be a link.

In the current workflow for testing, on every pull request to the main branch the CI workflow is triggered but also the release
branches. This is not necessary for the release. So it's required to ignore these branches during the testing.

Instead of merge every PR to the main branch, all the PR can be combined into a single PR with tests passing for all the
dependencies updates. In order to do this, a new branch can be created, this branch will have the same content of the main branch.
All the PR's for dependencies can be merged into this branch and create a PR to the main branch. This will allow testing
all the updates in a single PR instead of individuals PR and see the correct integration.

The target branch of dependabot should be the main branch. It's unnecessary in another branch to test the updated dependencies.