Implemented dependency injection for the data product endpoints

[vladimir-gladkii]

🚀	This description was created by Ellipsis for commit f0361bb

Summary:

Implemented dependency injection in DataProductRoutes using IDataProductUsecases and DataProductUsecases, enhancing testability and flexibility.

Key points:

• Implemented dependency injection in DataProductRoutes for data product endpoints.
• Introduced IDataProductUsecases interface and DataProductUsecases class for use case injection.
• Modified DataProductRoutes to accept IDataProductUsecases in constructor.
• Replaced direct usecases calls with self._usecases in methods.
• Updated routes initialization to use DataProductUsecases.
• Refactored tests to use mock use cases.
• Added create_client and create_usecases helper functions for test setup.
• Ensured tests cover scenarios for successful data retrieval and exceptions.

---

Generated with ❤️ by ellipsis.dev

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 7b97240 in 6 seconds

More details

• Looked at 205 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 1 drafted comments based on config settings.

1. server/app/rest_api/routes/tests/test_data_products.py:63

• Draft comment:
  The use of IQuery | None is unnecessary here since the query parameter is always provided. It should be IQuery. This applies to line 77 as well.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The use of IQuery | None in the test functions is unnecessary since the query parameter is always provided in the actual use case. It should be IQuery.

Workflow ID: wflow_8MElyqCINbhM6cm4

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

⌛ 6 days left in your free trial, upgrade for $20/seat/month or contact us.

[ellipsis-dev]

👍 Looks good to me! Incremental review on f0361bb in 26 seconds

More details

• Looked at 190 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. server/app/rest_api/routes/tests/test_data_products.py:53

• Draft comment:
  The list_usecase function is defined as a synchronous function, but it should be asynchronous to match the IDataProductUsecases interface.

        def async list_usecase(query: GetPaginated) -> list[DataProductEntity]:

• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The list_usecase function is used in a test context and does not need to be asynchronous. The test is not actually calling the method asynchronously, so the suggestion to make it async is not necessary. The comment is not about a change made in the diff, but rather about the existing code structure in the test.
  I might be overlooking the importance of consistency in the codebase, even in test mocks. However, since the test does not require asynchronous execution, the comment seems unnecessary.
  While consistency is important, the primary goal of the test is to verify functionality, not to adhere to interface patterns. The test functions correctly without the async keyword.
  The comment should be removed because it suggests an unnecessary change to a test mock function that does not need to be asynchronous.

2. server/app/rest_api/routes/tests/test_data_products.py:72

• Draft comment:
  The get_usecase function is defined as a synchronous function, but it should be asynchronous to match the IDataProductUsecases interface.

        def async get_usecase(connector_id: str, query: GetByID) -> DataProductEntity:

• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The IDataProductUsecases interface has asynchronous methods, and the get_usecase function in the test is synchronous. This mismatch could lead to issues if the interface expects asynchronous behavior. The comment seems to address a valid concern about interface compliance.
  The test might be intentionally using a synchronous function for simplicity or testing purposes, and the interface compliance might not be necessary in this context. The comment might be assuming that the test needs to strictly adhere to the interface.
  Even if the test is using a synchronous function for simplicity, it might still be beneficial to align with the interface to prevent potential issues or confusion in the future.
  The comment addresses a valid concern about interface compliance and should be kept to ensure the test aligns with the asynchronous nature of the IDataProductUsecases interface.

Workflow ID: wflow_qQQ2DPfXMXFKnKox

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

⌛ 3 days left in your free trial, upgrade for $20/seat/month or contact us.