dgoosens, 4 months ago

@greg0ire

#awesome
well done

video/mp4

thomastospace, 4 months ago

@greg0ire This is huge. 2.x was already released way before I had my first job, and at that job I started using it.

The fact that throughout my whole career so far, I could upgrade without any breaking changes is amazing.

I'm ready for this 3.x era. 🎉

rskuipers, 4 months ago

@greg0ire This is amazing news!

Does anyone know the reasoning behind dropping the UUID generator? Just curious.

https://github.com/doctrine/orm/blob/3.0.x/UPGRADE.md#bc-break-removed-classes-related-to-uuid-and-table-generator-strategies

greg0ire, 4 months ago

@rskuipers Yes, see https://github.com/doctrine/orm/issues/7312

rskuipers, 4 months ago

@greg0ire do I understand it correctly that because the databases aren't consistent in format, ORM/DBAL don't support it? And I'm guessing the ORM/DBAL is not interested in generating it in PHP land or having a fixed dependency like ramsey/uuid?

That makes sense, I hadn't considered that.

From the consumer's POV it's nice that it would default to UUID, but I see why that comes with too big of a cost.

greg0ire, 4 months ago

@rskuipers Yes, that's it, you can get even more details about it here: https://github.com/doctrine/dbal/issues/3167

rskuipers, 4 months ago

@greg0ire Thanks!

derrabus, 4 months ago

@rskuipers @greg0ire The USP of UUIDs is that you can create them in userland before the entity manager even knows about the record that you're about to persist. A UUID generator provided by the ORM feels like it will always be too late in the whole process to be really useful.

rskuipers, 4 months ago

@derrabus @greg0ire True, that's one USP. Another USP is that it's a safety net for enumeration attacks. Shouldn't be necessary but good to have.