Enhancing Prisma provider to Automatically Cast Primitive Type Properties and Handle Optional Fields

[juliano-soares]

Description:
The current state of the Prisma provider is powerful and efficient, but there are opportunities for enhancement in terms of convenience and automation when dealing with primitive type properties and optional fields. This proposal suggests two improvements that could streamline the usage and make the ORM even more developer-friendly.

1. Automatic Type Casting for Primitive Type Properties:

Current Behavior:
Currently, when defining primitive type properties, developers have to manually handle non-string type conversion. For example, if a property is defined as a number, the developer must manually add the variable's type as type.Int.

Proposed Enhancement:
It would be beneficial if Prisma provider could automatically handle type casting for primitive type properties. For example, in a scenario where the property is defined as type.Int, like so:

Before:

@prismaField({ type: type.Int })
phone!: number;

Prisma could automatically cast the provided data to an int when interacting with the database, eliminating the need for developers to handle this conversion manually.

After

@prismaField()
phone!: number; // <-Here

2. Direct handling of optional fields:

Current behavior:
When working with optional fields, we need to set the isOptional property to true.

Proposed improvement:
The proposal suggests a more intuitive approach to working with optional fields by fetching this information directly from the class property.

Before:

@prismaField({ isOptional: true })
bio?: string;

After:

@prismaField()
bio?: string; // <- Here

Benefits:

• Improved Developer Experience: These enhancements would simplify the development process by reducing the amount of manual code needed for type casting and handling optional fields.
• Code Readability: The proposed changes would lead to more concise and readable code, as developers would not need to write additional logic for type casting and optional field handling.
• Time Savings: Developers would spend less time on repetitive and error-prone tasks related to type conversions and optional field checks.