What is the library's (soft) position on pluralization of context and table name spacing?

So I’m teaching someone to use phoenix and I’m noticing a few different ways the gen tasks talk about context/modules/tables and I wanted to know what the official suggested pattern is for developers regarding pluralization and name spacing:

(I realize this is largely “do what you feel makes sense”)

mix phx.gen.context — Phoenix v1.7.10, mix phx.gen.auth — Phoenix v1.7.10, mix phx.gen.html — Phoenix v1.7.10, mix phx.gen.json — Phoenix v1.7.10, mix phx.gen.live — Phoenix v1.7.10, mix phx.gen.notifier — Phoenix v1.7.10

mix phx.gen.context Accounts User users
mix phx.gen.auth Accounts User users
  • plural context module
  • singular schema module
  • non-namespaced plural table

https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Auth.html#module-multiple-invocations

mix phx.gen.auth Store User users
mix phx.gen.auth Backoffice Admin admins
  • singular context module
  • singular schema module
  • non-namespaced plural table

https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Embedded.html

mix phx.gen.embedded Blog.Post title:string views:integer
  • Singular context and schema module, joined by “.”
  • No table name (makes sense)

https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Schema.html

mix phx.gen.schema Blog.Post blog_posts title:string views:integer
  • Joining context and schema module name, both singular
  • Table name is plural but namespaced by context

But also on the same page:

mix phx.gen.schema Accounts.Superhero superheroes secret_identity:redact password:string:redact
  • Same as above, but the context is plural
  • Same as above but the table name isn’t namespaced

My feeling after considering all your examples is that we can retain the following essential points:

  • Database tables are always named in the plural form.
  • Schema modules are always named in the singular.
  • Context modules can be named in either singular or plural, but there is always a hint of plurality related to the entity that the schema represents lurking underneath.

What I mean in the last point, I will try to show with your examples.

mix phx.gen.auth Store User users
mix phx.gen.auth Backoffice Admin admins

A single store is enough to manage all users. If the context was about managing multiple stores, we could name it in the plural form of store: Stores. The same goes for Backoffice.

I think we can also say the same thing about a context named Blog. The notion of plurality here is that a Blog is the space where we can manage all blog posts. We could have also called it Posts, but it feels to me, less inspired or appealing. ^^

Regarding your other concern, about adding the context namespace to the schema and table, I think it’s just to avoid name overlaps for tables and schemas.

The blog_posts is a good example, as we can integrate a blog into almost any website. So if we want to import a generic blog application into an existing web project, it’s possible that the said project already has a migration posts table for something else.

Of course, this is only my opinion and as you so aptly put it:

2 Likes

Basically what @Kurisu said.

The name of the context depends on what you want it to do. Like have a small blog app (that I don’t use, lol) that looks like this:

Blog
  Post
  Draft

This is because I only have one blog. If I had a bigger application where users could create many blogs, then I likely have something that looks like this:

Blogs
  Blog

Posts
  Post
  Draft

There are no hard and fast rules, the generators are more for learning and not really meant to be used forever.

And ya, again just re-enforcing what @Kurisu said, namespace your tables if you think it’s going to be a problem otherwise it doesn’t really matter. Ecto Schema names have no magical relation to their table names like it is in some ORMs.

1 Like