Incorrect value in Postman Doc for class passed into route

[jamespavett]

• I confirm that I have read and attempted the tips in the Troubleshooting Guide.

What happened?

1. I set my configuration to...
2. Then I ran php artisan scribe:generate ...
3. But I saw...

I am making use of Laravel apiResource groups for some of my models.

Within the controller I am using Laravel's dependency injection to get access to the class (in this instance User) straight away in the method. For example the following update function:

public function update(Request $request, User $user)
{
    ....
}

However inside the collection.json generated by running php artisan scribe:generate, the value assigned to the variable is just some random string. In the below screenshots for the user model it is getting the string velit passed to it, while in reality that should be an integer reflecting the ID of the resource.

Right now I am not sure if there is fault in the package of whether I am making a mistake somewhere, but I cannot see what else I can change on my end. Any help would be appreciated.

Screenshots and stack traces:

My environment:

• PHP version (from php -v): 7.4.3
• Framework (Laravel/Lumen): Laravel
• Laravel/Lumen version (from composer show laravel/framework or composer show laravel/lumen-framework): 8.16.1
• Scribe version (from composer show knuckleswtf/scribe): 2.3.0

[shalvah]

That's expected behaviour. That value does not come from the $user function parameter, but the {user} URL parameter. Scribe automatically picked that parameter up from your route's path and guessed that its type is string. If you don't want that, then document the parameter properly with @urlParam.

[jamespavett]

Cheers for getting back to me.

Is there no other way to get around this? Only reason I ask is because this sort of messes up with the PHP Doc comments I already have, they still request me pass any parameters through @param.

[carestad]

Wouldn't it be possible for Scribe to parse this differently? Maybe check the type hinted class in the controller rmethod and if it is a class that extends Laravel's Model, one can assume it is that model's primary key that is actually expected there and one could check the model's $keyType property to see if the primary key is an int (default) or string.

[shalvah]

Interesting suggestion that I can consider for v3, but how often do models have a $keyType? I've never seen it before, and I don't think Laravel sets it by default. Is it always:

• if no $keyType, assume int
• otherwise, use $keyType?

[carestad]

Interesting suggestion that I can consider for v3, but how often do models have a $keyType? I've never seen it before, and I don't think Laravel sets it by default. Is it always:

* if no `$keyType`, assume `int`

* otherwise, use `$keyType`?

Yep, that sounds about right. It is declared in Laravel's base model here: https://github.com/laravel/framework/blob/8.x/src/Illuminate/Database/Eloquent/Model.php#L61

And it can be fetched using ->getKeyType(), so for example: $keyType = (new User)->getKeyType().

I believe it can be string too in some circumstances, which is why I considered it more safe to just check it, otherwise I would just assume int anyway.

[shalvah]

Do people actually set it, though?

…

On Fri, May 21, 2021, 16:00 Alexander Karlstad ***@***.***> wrote: Interesting suggestion that I can consider for v3, but how often do models have a $keyType? I've never seen it before, and I don't think Laravel sets it by default. Is it always: * if no `$keyType`, assume `int` * otherwise, use `$keyType`? Yep, that sounds about right. It is declared in Laravel's base model here: https://github.com/laravel/framework/blob/8.x/src/Illuminate/Database/Eloquent/Model.php#L61 And it can be fetched using ->getKeyType() <https://github.com/laravel/framework/blob/8dcc5aab239ef3f57b36766fa7aec45701ade255/src/Illuminate/Database/Eloquent/Model.php#L1645>, so for example: $keyType = (new User)->getKeyType() — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#151 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNSD4OADRXDN542UL343J3TOZYRTANCNFSM4UJY4OVQ> .

[carestad]

I would think so, it is documented here: https://laravel.com/docs/8.x/eloquent#primary-keys Maybe UUID columns that are primary can be strings. So I would be open to it being strings every now and then.

[shalvah]

Alright. Noted for v3.

[shalvah]

🎉v3 is out now! Should be smarter with routes and URL parameters now.