GUID / UUID as id with laravel

If you want to make a very large project with laravel (or in general). You probably want to use Commands and Events aka CommandBus or maybe CQRS.

If you use a command approach you execute a command, have a handler for it which handles the command and you can than fire an event that it is done.

If you 'listen' for that event, you can run more things later on, for example:

CommentOnPostCommand --> CommandOnPostCommandHandler --> (fires) CommentHasBeenPosted

So now you can add more stuff to that event...

Ok UUID, if you use Commands it is nice to know what the actual 'ID' is before it is in the database, if you fire an event with the command (and it's data) you won't have access to the ID because it is a simple DTO (Data Transport Object), If you later want to get the ID to attach it somewhere or I don't know what you want to do you will have to fetch it so UUID is a good idea :)

Oh a package? No idea sorry :/

@malfait.robin thank you for reply . but what is the connection between GUID/UUID and the Command Design pattern ?

If you have a website that has servers in multiple regions and for speed you want to write to a database in each region, and you needed all the data to sync up. Then incremental ID's would not allow you to sync them, but you could use a UUID.

I've only read a little about it, so I wouldn't know the best way to implement it.

Here is a package for laravel. https://github.com/webpatser/laravel-uuid

In most of my projects, I personnaly use both incremental ID and UUID:

• UUID is more secure (as much as security by obscurity can be) for public (URL) use.

• Integer comparison are a lot faster than string comparison for primary/foreign keys in your database.

For the package, https://github.com/webpatser/laravel-uuid is indeed a good choice.

@AlnourAltegani the link is exactly what @rieves said :)

Just wondering how it went using uuids for your id? I have had success with it on two projects but one minor issue was that I did not get the ID back from a newly created model, it was always null even though it saved fine. This meant I had to save the ID prior to the creation of the model then set the model ID with it to return a full model.   Overall though it is so easy to do and makes it so much easier to have different queue workers/servers all posting back to the same remote database as they process that queue etc.  Btw I have some earlier notes on it here https://www.alfrednutile.info/posts/94

thank you @alfrednutile for reply . what about the performance ? is it better to save it in bin col type or string ?

theres a good blogpost from percona about mysql and uuid: http://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/

Here is my own package will automatically generate Uuid and assign it to uuid field.

https://github.com/EmadAdly/laravel-uuid

Why now store the IDs in a SESSION variable and remove the entire headache?