Phoenix: Consider generating ecto migration with primary key type bigserial/bigint by default

[michalmuskala]

Related to: https://github.com/elixir-ecto/ecto/issues/2135

The downsides of using bigserial/bigint for primary key are very small - primarily data size. But if your dataset is small that doesn't really matter and if your dataset is big, you'd want to use bigserial/bigint anyway. It seems like a much saner default.

By adding the types explicitly in the generator this can be done in a backwards-compatible way. The new convention can be used only in the new phx generators to increase compatibility even further.

[josevalim]

I would rather follow whatever Ecto does instead of fragmenting. Maybe we can support this somehow in Ecto through a key/configuration?

[michalmuskala]

It's already a configuration on the table by passing the type explicitly. Or do you mean like a global configuration?

[josevalim]

Global or repo configuration.

[chrismccord]

I am +1 for this change and can't argue at all with the logic of the change. What do we need on the echo side to get this in? It would be nice to land this asap for the new generators as we have guides material that is ready to go and will need changes.

[samdvr]

What are your thoughts on using uuid as the primary key? the downside is readability but the advantage is avoiding key collisions, which becomes crucial in complex distributed system that have multi-master nodes. @michalmuskala @josevalim @chrismccord

[michalmuskala]

As somebody who for the last 2 years maintained an application that used UUIDs for everything, I don't think this is a good idea. There's a number of disadvantages:

• you lose the natural order of rows,
• debugging is painful, you have to always copy things around - there's no chance you're going to remember a UUID - even in dev or test,
• with bigints the concern was the size blow-up, UUIDs are even larger,
• and probably more.

One important thing here is that we're talking about using them with RDBMS - mult-master deploys of relational databases aren't that frequent and I'm not sure the advantage of easy distribution is really there.

It often makes sense to use UUIDs in some part so of the application or for some tables (especially those that represent some kind of "root" resource), but using them for everything, in my opinion, creates more problems than it solves.

[josevalim]

Yes, I don't think it is a reasonable default for the reasons @michalmuskala said, but you can pass the --binary-id flag if you want to phoenix to use uuids.

[michalmuskala]

Are we abandoning the bigint/bigserial proposal as well?

[scrogson]

👍

[chrismccord]

I re-opened assuming @josevalim accidentally closed it. I would still like to get this in, so I'll re-iterate, what is stopping us on the Ecto side from making this change?

[josevalim]

@chrismccord there won't be a release on Ecto side on time for Phoenix v1.3. So let's get that out and then we discuss how to move this forward in time for v1.4.