Validation not working for new entry in replaceOne route

Hi, I was currently struggling with data validation in the PUT method since it Creates or Updates an entity I thought it would respect the corresponding CrudValidationGrup depending on the actual action it’s going to perform.

But after some digging, I realized that the “problem” was in this line and occurred me that is too hard to decide what validation group it’s going to use at the route creation.

Since the validation occurs before the endpoint actually getting hit and therefore before it can check entity existence, I’m not sure what would be the best approach to this.

From the top of my head what I can think of is:

• Change the mentioned line to make PUT use the same validations as POST (probably the easiest way to change, but I’m not sure if it can bring any hidden bugs. I will open a CR for this).
• Change replaceOne to be a route that does no validation and just checks user existence and redirects to the appropriate route with the appropriate validations (may increase the overhead for each call)
• Create a new CrudValidationGroup (I don’t think that helps very much since it will probably be used at the same places as the CREATE)

For now I can overcome this by hiding the replaceOneBase route, creating one of my own and redirecting the call to replaceOneBase after validation. The problem is that I don’t know an easy way of adding the ValidationPipe with the correct configurations besides of creating a new controller and overriding createOneBase (what is terrible).

[cleivson]

I agree that the custom DTO would come first in terms of prioritization as it adds more flexibility in terms of validation and data hiding.

in general, it should be in the same places as the CREATE, except maybe it also should cover some primary columns, or auto-generated ones, because PUT method means you need to send the whole resource but not the partial resource as you might send it on PATCH request.

I partially agree on that, I just don’t understand why should PUT validate more fields than create, but I accept that it could.

If we had to add a replace validation group, I think it should be complimentary to create since create defines the minimum requirements for registering an entity, no method should allow less than that.

[jonahsnider]

I have a similar issue with CRUD validation groups where it seemed the groups were being triggered on all write/create/update requests. It’s causing a major headache because the CREATE validation is being triggered on PATCH requests.