Db interface vehicles CRUD implemented #150

2025-12-03T23:20:40Z

vascodias23 commented

2025-12-03 23:20:40 +00:00

(Migrated from github.com)

Note: tests passed fine, but with warnings. Not sure if the warnings are relevant or not:

PydanticDeprecatedSince211: Accessing the 'model_fields' attribute on the instance is deprecated. 
Instead, you should access this attribute from the model class. 
Deprecated in Pydantic V2.11 to be removed in V3.0. 
res = object.__getattribute__(self, item)

Note: tests passed fine, but with warnings. Not sure if the warnings are relevant or not: ``` PydanticDeprecatedSince211: Accessing the 'model_fields' attribute on the instance is deprecated. Instead, you should access this attribute from the model class. Deprecated in Pydantic V2.11 to be removed in V3.0. res = object.__getattribute__(self, item) ```

copilot-pull-request-reviewer[bot] (Migrated from github.com) reviewed

2025-12-03 23:27:10 +00:00

copilot-pull-request-reviewer[bot] (Migrated from github.com) left a comment

Pull request overview

This PR implements the complete CRUD (Create, Read, Update, Delete) operations for the VehicleRepo class, replacing NotImplementedError stubs with functional implementations using the Beanie ODM for MongoDB. The implementation enables full vehicle management capabilities in the application, including creating vehicles, retrieving them by various criteria, updating vehicle data, and deleting vehicles from the database.

Key Changes

Implemented all five CRUD methods using Beanie ODM patterns for MongoDB operations
Added error handling with try-catch blocks and error logging for all methods
Used appropriate Beanie methods (insert(), get(), find_one(), find(), set(), save(), delete()) for database operations

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

## Pull request overview This PR implements the complete CRUD (Create, Read, Update, Delete) operations for the `VehicleRepo` class, replacing `NotImplementedError` stubs with functional implementations using the Beanie ODM for MongoDB. The implementation enables full vehicle management capabilities in the application, including creating vehicles, retrieving them by various criteria, updating vehicle data, and deleting vehicles from the database. ### Key Changes - Implemented all five CRUD methods using Beanie ODM patterns for MongoDB operations - Added error handling with try-catch blocks and error logging for all methods - Used appropriate Beanie methods (`insert()`, `get()`, `find_one()`, `find()`, `set()`, `save()`, `delete()`) for database operations --- 💡 <a href="/AndreFerreira5/starranja/new/main/.github/instructions?filename=*.instructions.md" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Add Copilot custom instructions</a> for smarter, more guided reviews. <a href="https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Learn how to get started</a>.

src/repository/vehicle.py

					
				@ -26,9 +26,13 @@ class VehicleRepo:

				        Raises:

Use the @handle_repo_errors decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in src.repository.decorators and is used throughout WorkOrderRepo.

Example:

@handle_repo_errors("create_vehicle")
async def create_vehicle(self, vehicle_data: VehicleCreate) -> Vehicle:
    logger.info(f"Creating vehicle with license plate {vehicle_data.license_plate}")
    vehicle = Vehicle(**vehicle_data.model_dump())
    await vehicle.insert()
    return vehicle

Use the `@handle_repo_errors` decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in `src.repository.decorators` and is used throughout `WorkOrderRepo`. Example: ```python @handle_repo_errors("create_vehicle") async def create_vehicle(self, vehicle_data: VehicleCreate) -> Vehicle: logger.info(f"Creating vehicle with license plate {vehicle_data.license_plate}") vehicle = Vehicle(**vehicle_data.model_dump()) await vehicle.insert() return vehicle ```

src/repository/vehicle.py

					
				@ -41,9 +45,9 @@ class VehicleRepo:

				        Returns:

				            Vehicle document if found, None otherwise

Change logging level from logger.info to logger.debug for read operations. The codebase pattern (see WorkOrderRepo) uses logger.debug for retrieval operations and reserves logger.info for write operations (create, update, delete).

        logger.debug(f"Retrieving vehicle by ID: {vehicle_id}")

Change logging level from `logger.info` to `logger.debug` for read operations. The codebase pattern (see `WorkOrderRepo`) uses `logger.debug` for retrieval operations and reserves `logger.info` for write operations (create, update, delete). ```suggestion logger.debug(f"Retrieving vehicle by ID: {vehicle_id}") ```

Use the @handle_repo_errors decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in src.repository.decorators and is used throughout WorkOrderRepo.

Example:

@handle_repo_errors("get_by_id")
async def get_by_id(self, vehicle_id: ObjectId) -> Vehicle | None:
    logger.info(f"Retrieving vehicle by ID: {vehicle_id}")
    return await Vehicle.get(vehicle_id)

Use the `@handle_repo_errors` decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in `src.repository.decorators` and is used throughout `WorkOrderRepo`. Example: ```python @handle_repo_errors("get_by_id") async def get_by_id(self, vehicle_id: ObjectId) -> Vehicle | None: logger.info(f"Retrieving vehicle by ID: {vehicle_id}") return await Vehicle.get(vehicle_id) ```

src/repository/vehicle.py

					
				@ -58,3 +62,3 @@

				        """

				        logger.info(f"Retrieving vehicle by license plate: {license_plate}")

				        logger.debug(f"Retrieving vehicle by license plate: {license_plate}")

Use the @handle_repo_errors decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in src.repository.decorators and is used throughout WorkOrderRepo.

Example:

@handle_repo_errors("get_by_license_plate")
async def get_by_license_plate(self, license_plate: str) -> Vehicle | None:
    logger.info(f"Retrieving vehicle by license plate: {license_plate}")
    return await Vehicle.find_one(Vehicle.license_plate == license_plate)

Use the `@handle_repo_errors` decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in `src.repository.decorators` and is used throughout `WorkOrderRepo`. Example: ```python @handle_repo_errors("get_by_license_plate") async def get_by_license_plate(self, license_plate: str) -> Vehicle | None: logger.info(f"Retrieving vehicle by license plate: {license_plate}") return await Vehicle.find_one(Vehicle.license_plate == license_plate) ```

Change logging level from logger.info to logger.debug for read operations. The codebase pattern (see WorkOrderRepo) uses logger.debug for retrieval operations and reserves logger.info for write operations (create, update, delete).

        logger.debug(f"Retrieving vehicle by license plate: {license_plate}")

Change logging level from `logger.info` to `logger.debug` for read operations. The codebase pattern (see `WorkOrderRepo`) uses `logger.debug` for retrieval operations and reserves `logger.info` for write operations (create, update, delete). ```suggestion logger.debug(f"Retrieving vehicle by license plate: {license_plate}") ```

src/repository/vehicle.py

					
				@ -76,3 +80,3 @@

				        raise NotImplementedError("get_by_client_id method not yet implemented")

				        return await Vehicle.find(Vehicle.client_id == client_id).to_list()

				    @handle_repo_errors("update_vehicle")

Change logging level from logger.info to logger.debug for read operations. The codebase pattern (see WorkOrderRepo) uses logger.debug for retrieval operations and reserves logger.info for write operations (create, update, delete).

        logger.debug(f"Retrieving vehicles for client: {client_id}")

Change logging level from `logger.info` to `logger.debug` for read operations. The codebase pattern (see `WorkOrderRepo`) uses `logger.debug` for retrieval operations and reserves `logger.info` for write operations (create, update, delete). ```suggestion logger.debug(f"Retrieving vehicles for client: {client_id}") ```

Use the @handle_repo_errors decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in src.repository.decorators and is used throughout WorkOrderRepo.

Example:

@handle_repo_errors("get_by_client_id")
async def get_by_client_id(self, client_id: ObjectId) -> list[Vehicle]:
    logger.info(f"Retrieving vehicles for client: {client_id}")
    return await Vehicle.find(Vehicle.client_id == client_id).to_list()

Use the `@handle_repo_errors` decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in `src.repository.decorators` and is used throughout `WorkOrderRepo`. Example: ```python @handle_repo_errors("get_by_client_id") async def get_by_client_id(self, client_id: ObjectId) -> list[Vehicle]: logger.info(f"Retrieving vehicles for client: {client_id}") return await Vehicle.find(Vehicle.client_id == client_id).to_list() ```

src/repository/vehicle.py

					
				@ -93,0 +98,4 @@

				            return None

				        update_dict = update_data.model_dump(by_alias=True, exclude_unset=True)

[nitpick] The if update_dict: check is inconsistent with the pattern in WorkOrderRepo.update() (lines 245-249), which always calls set() and save() regardless of whether the update dictionary is empty. This means that with an empty update, WorkOrderRepo will still update the updated_at timestamp, while VehicleRepo won't.

Consider removing this check for consistency, or explicitly document the intended behavior when update_data has no fields set.

            await vehicle.set(update_dict)
            # Trigger save hook to update `updatedAt` field
            await vehicle.save()

[nitpick] The `if update_dict:` check is inconsistent with the pattern in `WorkOrderRepo.update()` (lines 245-249), which always calls `set()` and `save()` regardless of whether the update dictionary is empty. This means that with an empty update, `WorkOrderRepo` will still update the `updated_at` timestamp, while `VehicleRepo` won't. Consider removing this check for consistency, or explicitly document the intended behavior when update_data has no fields set. ```suggestion await vehicle.set(update_dict) # Trigger save hook to update `updatedAt` field await vehicle.save() ```

Use the @handle_repo_errors decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in src.repository.decorators and is used throughout WorkOrderRepo.

Example:

@handle_repo_errors("update")
async def update(self, vehicle_id: ObjectId, update_data: VehicleUpdate) -> Vehicle | None:
    logger.info(f"Updating vehicle: {vehicle_id}")
    vehicle = await Vehicle.get(vehicle_id)
    if not vehicle:
        return None
    
    update_dict = update_data.model_dump(by_alias=True, exclude_unset=True)
    
    if update_dict:
        await vehicle.set(update_dict)
        # Trigger save hook to update `updatedAt` field
        await vehicle.save()
    
    return vehicle

Use the `@handle_repo_errors` decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in `src.repository.decorators` and is used throughout `WorkOrderRepo`. Example: ```python @handle_repo_errors("update") async def update(self, vehicle_id: ObjectId, update_data: VehicleUpdate) -> Vehicle | None: logger.info(f"Updating vehicle: {vehicle_id}") vehicle = await Vehicle.get(vehicle_id) if not vehicle: return None update_dict = update_data.model_dump(by_alias=True, exclude_unset=True) if update_dict: await vehicle.set(update_dict) # Trigger save hook to update `updatedAt` field await vehicle.save() return vehicle ```

src/repository/vehicle.py

Use the @handle_repo_errors decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in src.repository.decorators and is used throughout WorkOrderRepo.

Example:

@handle_repo_errors("delete")
async def delete(self, vehicle_id: ObjectId) -> bool:
    logger.info(f"Deleting vehicle: {vehicle_id}")
    vehicle = await Vehicle.get(vehicle_id)
    if not vehicle:
        return False
    
    await vehicle.delete()
    return True

Use the `@handle_repo_errors` decorator instead of manual try-catch blocks for consistency with the codebase pattern. The decorator is available in `src.repository.decorators` and is used throughout `WorkOrderRepo`. Example: ```python @handle_repo_errors("delete") async def delete(self, vehicle_id: ObjectId) -> bool: logger.info(f"Deleting vehicle: {vehicle_id}") vehicle = await Vehicle.get(vehicle_id) if not vehicle: return False await vehicle.delete() return True ```

GFMpt13 (Migrated from github.com) requested changes

2025-12-06 16:42:33 +00:00

GFMpt13 (Migrated from github.com) left a comment

You should follow the copilot review. The main focus is the @handle_repo_errorsand the logger.debug
Fix that and the this PR is going ready to be merged

You should follow the copilot review. The main focus is the @handle_repo_errorsand the logger.debug Fix that and the this PR is going ready to be merged

src/repository/vehicle.py

					
				@ -26,9 +26,13 @@ class VehicleRepo:

				        Raises:

Copilot is correct, you should use @handle_repo_errors to match the codebase pattern. Follow the example of another repository, like workOrders, to get an ideia.

src/repository/vehicle.py

					
				@ -41,9 +45,9 @@ class VehicleRepo:

				        Returns:

				            Vehicle document if found, None otherwise

Copilot is correct.

Same situation as before, use @handle_repo_errors.

AndreFerreira5 commented

2026-01-16 17:51:00 +00:00

(Migrated from github.com)

@vascodias23 you still have requested changes to do, please go ahead and do it so we can advance with the development

Sign in to join this conversation.

No reviewers

GFMpt13

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

AndreFerreira5/starranja!150

Rows
Columns