Can I use Unique rule with ignore & map ID from route params?

[ragulka]

I have a use-case where I need to add a Unique validation rule to a data object, which should ignore the current object's ID. Very much like described here - "Forcing A Unique Rule To Ignore A Given ID".

This data object is typehinted in the controller, so it's used instead of a FormRequest class. The frontend does not provide the ID in the payload - it's only available in the route params.

My question is twofold:

• Is it possible to have the Unique rule attribute reference the current object's ID property (or the ID from the payload), instead of a hardcoded value?
• Can the SongData class somehow automatically map the ID from route params to the SongData::$id property?

Route & controller

Route::patch('/songs/{song}', [SongController, 'update']);

class SongController extends Controller {

    public function update(Song $song, SongData $data)
    {
        // here, $data->id is empty, even though $song->id is present
    }
}

SongData.php

class SongData extends Data
{
    public function __construct(
        public ?int $id,
        #[Unique('songs', ignore: 'id' )] // this probably won't work - 'id' is just a string
        public ?string $external_id,
        public ?string $title,
        public ?string $artist,
    ) {
    }

    public static function rules(Request $request, array $payload) : array
    {
        // Here, $payload['id'] is empty, because it's not provided in the request body.
        // But the ID is present in the route params, so I can technically fetch it from the route params:
        $payload['id'] = $request->route()?->parameter('song')->id;
        // but, is there a way to have laravel-data do the above automatically?

        return [
            'external_id' => [Rule::unique('songs')->ignore(Arr::get($payload, 'id'))],
        ];
    }
}

[ragulka]

I was assuming I can use the fromRequest static method to append the ID to the request data before the data is validated, like this:

public static function fromRequest(Request $request): static
{
    return static::from(array_merge($request->all(), ['id' => $request->route()?->parameter('song')->id]));
}

Unfortunately, it looks like validation runs before the fromRequest method is even called. This means that if the request body is missing the ID (but it is in the route params), and one of the validation rules depends on the ID, the validation will fail.

[ragulka]

Looks like DataFromSomethingResolver is responsible for validating the request payload before calling fromRequest.

I assume this is by design, although a bit unexpected. My assumption was that I can freely modify either the request, or customize how request data is mapped to the data object, and then have it validated.

I now see that validation happens before the data object is even created, and there is no way to customize how the request payload is mapped before validation. The pipeline is hardcoded, and I did not see nay extension/customization points.

I don't think my use-case for setting the object ID before validation is uncommon - after all, it is required for proper validation rules. Also, I cannot trust user input for the ID - after all, it may be different from the route ID param, ion which case the validation rule itself would be invalid... Hence the need to override it with the value from the route param.

I guess I have 2 options now:

• Either build a middleware that maps object IDs in route param to request body
• Access the current request object directly in the static rules() method

I'm not a fan of either, tbh.

[rubenvanassche]

The reason why the pipeline runs before the custom creation method is because at that point you want to make sure the data you're receiving from the frontend is completely validated. The reason for the alternative pipeline was for performance reasons but I don't think that actually will be a huge issue so I've removed it.

What I would do:

1. Create a new attribute like #[FromRouteModel('song', 'id')] or even #[FromRouteModel('song')] since we can use the name of the property
2. Add a new pipeline after MapPropertiesDataPipe called FillRouteProperties which checks each property for such an attribute and loads it into the payload
3. Add/Update the unique rule to also be able to get the value from the payload, this is probably the most difficult one since it requires a lot of rewrites within the data validation rules resolving part

At the moment I don't have the time to build such a thing 😄. I had the plan to completely rewrite the validation engine for data v3 but that's not something I can start working on in the next months.

So you're always welcome to PR such a thing!

[ragulka]

The reason why the pipeline runs before the custom creation method is because at that point you want to make sure the data you're receiving from the frontend is completely validated

Why would you want to make sure the payload is validated at this point? I'm not sure I understand this assumption. When I use magic creation methods, I don't care if the payload is valid (yet). I want to use this method as a sort of mapper and then pass the mapped payload to the built-in pipeline, so that it can then validate it.

Looking at the docs, all the magic method seem to instantiate the data object directly using new self().

It seems to me a better option would be to use self::validateAndCreate(), and always pass an array as the payload. This is how I would do it:

public static function fromRequest(Request $request): static
{
    return static::validateAndCreate(array_merge($request->all(), ['id' => $request->route()?->parameter('song')->id]));
}

[rubenvanassche]

The reason behind this is protecting people who expect a request already being validated since the same happens when you inject a Request in a controller.

Maybe we should a config option which allows you to disable this behavior 🤔 .

Also did you already have a look at prepareBeforePipeline which allows you to inject properties before the whole process.

[ragulka]

@rubenvanassche I see. I still find it somewhat confusing, at least from where I'm coming from 😅. I did look at prepareBeforePipeline and I like it a little better than using fromRequest:

public static function prepareForPipeline(Collection $properties) : Collection
{
    if ($songId = request()?->route('song')?->id) {
        $properties->put('id', $songId);
    }

    return $properties;
}

However, I was not able to use use DI to inject the Request in the method signature, which is why I'm using the global request() helper.

With the above, I at least no longer need to access the Request instance in my rules method - the id will be injected into the $payload now.

One last thing, though - would it be possible to make the #[Unique('songs', ignore: 'id' )] attribute-rule use the value of id key from the payload, rather than a literal 'id' string, like it does now?

[ragulka]

Never mind my last question - I saw the discussion here.

[lava83]

Sorry if I say so, but this currently makes laravel-data completely unusable to replace it completely with, for example normal laravel form requests. We have tons of validations, especially unique ones, that rely on parameters in the request and are included in the queries. And in my opinion the name of the method: fromRequest() suggests that the validation is executed after or in this method and not before.

[rubenvanassche]

You're always welcome to send in a PR fixing this.

[mafeijam]

here how I do a quick hack to override the rule in controller

class AccountData extends Data
{
    public function __construct(
        #[Unique(Account::class)]
        public string $name,
        public string $status,
        public string $type,
        public string $ccy
    ) {

    }
}

  public function update(Account $account, Request $r)
  {
      $rules = AccountData::getValidationRules($r->toArray());
      $rules['name'][2]->ignore($account);

      $account->update($r->validate($rules));

      return back()->with('message', "Account [$account->name] updated");
  }