Add method to retrieve first random element

[czernika]

Hi there!

I'm currently seeding my database with fake data. In order to fill foreign ids I need to get any existing model and pass its id. And I found myself repeating same line for different models like

User::inRandomOrder()->first();

Maybe it would be nice to add something like?

User::firstRandom();

[henzeb]

Random in tests is not a good idea. As it may fail randomly.

That being said, you can extend laravel's Eloquent Builder using macro's.

[czernika]

Yes, I can create macros, helpers, anything - but main point is not to HOW can I make it, but maybe just to add it by default into Laravel package - that's why I put in Idea section.

Recent example - findOr() method. It easy to check by my own if model exists or not and assign any value to it, but method was released. And that's cool!

Same thing here. I want to have this method out of the box. That's just idea to discuss

Now my workflow is

1. Install
2. Create helper
3. Enjoy

I want to shorten it to Install & Enjoy)

[henzeb]

then you should make a package. Because the chance of this being added to he core is slim as it's just a shortcut. Taylor Otwell is very picky in what goes in, as he wants to prevent the framework from growing too fast.

[czernika]

That's the point for discussion - should it be added or not. If not, why? Because I can open PR for Builder method like, there's nothing fancy, plus make tests

public function firstRandom($seed = '')
{
    return $this->inRandomOrder($seed)->first();
}

but does it worth it?

P.S. I see no point in creating package for just one method. Also it still will be the same workflow - install - install package - enjoy)

[henzeb]

it really depends on the use case. is there a use case everybody uses all the time? usage in tests is not one of them, as again, random values in tests are unpredictable. if we add shortcuts for everything we think it's too long to type, the size of laravel framework would become immense...

[BrekiTomasson]

Something I do in most of my projects is build an \App\Models\Model class that looks something like this:

<?php

declare(strict_types = 1);

namespace App\Models;

use Illuminate\Database\Eloquent\Builder as EloquentBuilder;
use Illuminate\Database\Eloquent\Model as EloquentModel;
use Illuminate\Support\Facades\Cache;

/**
 * @mixin EloquentModel
 * @mixin EloquentBuilder
 */
class Model extends EloquentModel
{
    public static function getCachedValueFromId(int $id, string $value = 'name') : mixed
    {
        $tag = str(static::class)->lower()->afterLast('\\')->toString();

        return Cache::tags('model_cache')->remember(
            "${tag}.${id}.${value}",
            now()->addWeek(),
            static fn () => self::find($id)?->{$value},
        );
    }

    public static function hasRowWithValue(string $field, int|string|float $value) : bool
    {
        return Cache::tags('data')->remember(
            static::class . '.' . $field . '.' . $value,
            now()->addDay(),
            static fn() => self::where($field, $value)->exists(),
        );
    }
}

That way, the Models in the project can just extend App\Models\Model instead of extending Illuminate\Database\Eloquent\Model, and they all get access to the methods I put in there. For the method you're suggesting, something simple like this should do the trick:

public static function firstRandom() : self|null
{
    return self::inRandomOrder()->first();
}

[henzeb]

Why not using macro's ?

[BrekiTomasson]

Well, mainly because I didn't understand Macros as well as I do now when I first started doing this, but mainly because macros aren't cleanly detected by my IDE without going through hoops, can't be . Extending Laravel's base class like this also feels far more "Native PHP" and doesn't run the same kinds of risks of breaking if anything changes in ´Macroable´ down the line.

That said, I do use Macros for other things, such as if I want to add methods to Arr or Builder, but for the more basic "extendable" classes like Controller, Model and a handful of others, I find it far easier to just extend the base class and use my own version. You see similar things happening in Laravel, like how Illuminate\Support\Carbon is just a wrapper around Carbon\Carbon with a single extra method and the trait Conditionable added.

[henzeb]

The idea with macroables is not only to extend classes, but also in a way it is always available. if you want something to be available on all your Models, and some developers just use the regular implementation, it might break. You cannot force it by checking upon your base model if you need a specific model. With the Carbon implementation, that problem does not exist. if you need the Conditionable methods, you type hint Laravel's carbon, if not, it doesn't matter.