How can I generate a dynamic ID?

@yazeedayyash Okay, that works for generating it, but how can I guarantee uniqueness here?

@MohamedTammam

use Carbon\Carbon;
protected static function boot()
{
    parent::boot();
    static::saving(function ($model) {

        $prefix = Carbon::now()->format('Y-m');

        $count = $model->where('created_at', 'LIKE', $prefix . '%')->count();
        $model->slug = $prefix . '-' . $count++;
    });
}

This is assuming you arent deleting any orders.

@automica Yeah, that's exactly what I reached so far and yea I don't physically delete any orders from DB.

The only problem I have now is, how to ensure the uniqueness of it and not getting an error for unique constrain if I get too many orders at once.

Or older syntax.

static::saving(function ($model) {
    $model->uuid = \Ramsey\Uuid\Uuid::uuid4();
});

@bugsysha Unfortunately the business people doesn't want an UUID.

@MohamedTammam you can always pull it through sha1().

static::saving(function ($model) {
    $model->uuid = sha1(\Ramsey\Uuid\Uuid::uuid4());
});

@automica Yeah, that's correct and the {id} part should reset every month.

@automica how do you mean "defining the actual id"?

@bugsysha I’d be using autoincrement integer or uuid for model id and what I suggested previously tor order reference

@automica what would be the benefit of such approach? Auto-incrementing ID can be used to keep things more readable. UUID can be used on a presentation layer. One doesn't exclude the other. But still can't figure out why would you want to have such a format for the orders.

@bugsysha Year, Month and current order number that month is much easier to parse for a human than a UUID. its obvious that

2021-10-001 and 2021-10-002 are orders from the same month.

@bugsysha It's a business requirement.

@automica I understand the readability side, but I was hoping there was something else I was missing. For me that is only important for invoicing systems. For all other use cases, I would go with something "random". If you check Amazon you will see that they don't use such an approach. But thanks for clarifying.

@MohamedTammam business requirements are sometimes stupid and you should point those situations out. Like I said, only invoicing systems to some extent make sense for such a format. Where you need people to be able to roughly guess the invoice number. But even that is debatable. If you are going with the mentioned format then shouldn't you somehow represent a user also in the invoice number? That way you can remember some important customers and find their orders even easier.

@jlrdw Can't do that, because I need the last digit to reset to 1 every new month.

@MohamedTammam I agree with @bugsysha above, there are times when you have to explain these things and go with plan b. It will be hard to get unique numbers like you asked. You could monthly have a table of numbers, use one and delete from table, but that will not always prevent duplicates.

Just saying when you have multi-users at same time, this has been a problem for many web programmers. Note also that even using random sometimes repeats.

The table per month with numbers could work but you would have to implement locking on that table.

@jlrdw I will of course try to explain that to them, but for now I'm testing all approach on another column not the ID column. so at least I'm preventing errors with relationship if I had duplicates.

@Snapey thank you. One more point to why it needs to be scoped with the user-id in the order number.

@newbie360 what is the pricing model is based on execution time?

@bugsysha

maybe something like this, will this work ? imagine create 1000 invoice records at the same time, but the create action is proccess one by one

// use queue on create Invoice
dispatch(function () {
    sleep(5); // make sure sleep is top of other code

    $lastInvoiceNumber = Invoice::whereYear('created_at', now()->year)
        ->whereMonth('created_at', now()->month)
        ->orderByDesc('id')
        ->value('invoice_number'); // get first record value

    $newInvoiceNumber = is_null($lastInvoiceNumber)
        ? now()->format('Y-m-000001') // starting a new month format: 2021-11-000001
        : ++$lastInvoiceNumber;

    Invoice::create(['inovice_number' => $newInvoiceNumber]);
});

@newbie360 what on earth are you on about?

sleep ?

have you heard of a counter?

This is really worrying considering you give others advice

@Snapey

Counter? can you explain

@newbie360

the thing you learn in the first hour of php. $counter++

@Snapey

you mean this ?

++$lastInvoiceNumber;

$a = '2021-10-000011';
dd(++$a); // '2021-10-000012

yes i'm newbie for coding, i think remove sleep(5) is ok

and the code block isn't inside a loop, just imagine 100 peoples adding inovice at the same time, all goes to jobs table then proccess one by one

@newbie360 know that sleep(), usleep() and other similar purpose features are not scalable solutions. That should "never" be part of your code. Also, as pointed out by @snapey, that might have concurrency issues.

@bugsysha oh ok i will avoid use sleep(), Thank you

@MohamedTammam catching up afterwards will be a problem if you value the sequence of the numbers since the catch up order number will be at the end, and possibly also in a different month.

@Snapey I have created at and the normal ID which is auto_increment that I can validate using them.

That what got in my mind so far. Because that number only business-related stuff so I can only use them if I want to show the order ID.