Italo

> I'm also thinking we parse/store/treat `ULID` values differently to `UUID` values? Apart for some flag to represent them differently, I don't think it should be stored differently than UUID...

Not having to parse/create it on the frontend, optimized storage, and hopefully, allowing SurrealDB to generate one.

> So what's the benefit of treating a ULID as a UUID underneath? As opposed to having a new `ULID` type - which coincidentally is easier to implement. Well, nothing....

Taking the reference of the repository being ghosted in two years, and being `ULID` a solution for a problem that (now) is being solved officially by the new `UUID` versions,...

Weird. Supposedly, when you push the setting to migrate, it will create settings for all users, so there is no need to "initialize them" on retrieval: these are already initialized.

If not, I would rather add a command to fill the settings to the historic users, rather adding an additional query check.

Gonna check it out. AFAIK, it "scans" the models for those having the package trait, and then queries them to make a bag of settings for each of them. If...

No ETA BTW, hands full.

Did you dump your autoload? Laraguard doesn't uses `require` to pick up the models, it just infers them using PSR-4. The only `require` used is from the `settings.php`. The stack...

Hands full and overtime guys, you will have to sit this one out.