Database column convention

[lffg]

Brief history

Yeah, I know. We have a conflict here. JavaScript has the camelCase convention. SQL has the snake_case convention. This causes a mix of conventions in our AdonisJs code. Take a look at the following example:

const { created_at } = await User.find(id)

ESLint would probably complain about the above code, and then I'll need to do something ugly like the following:

const { created_at: createdAt } = await User.find(1)

See the problem?

Proposal

I don't see any problem in using camelCase column names in my SQL database. But I followed the snake_case convention for the database columns because the "created_at" and "updated_at" columns were already following that pattern. To keep it consistent, I choose to use snake_case for the database and camelCase for JavaScript variables and such.

This approach of using two conventions in the same codebase tends to create an inconsistent code. Then, to keep it straight with the JavaScript camelCase convention, why don't we use camelCase column names in AdonisJs databases? What do you guys think?

To enforce that, I suggest that we rename the created_at and updated_at column names to createdAt and updatedAt respectively in order to follow the camelCase pattern.

What problem does it solve?

This proposal solves the inconsistency caused by using two conventions (camelCase and snake_case) in the same codebase.

Are you willing to work on it?

If we (the community) agree to use the camelCase convention in our database, yes. :)

[thetutlage]

The simplest way to do is have camelCase in AdonisJs codebase and snake_case in database and ORM takes care of converting them to the right case.

Moving database to camelCase may have some issues, especially PostgreSQL. Also, if you are part of a big team, where Database is managed by some DBA's, then you will have a hard time convincing them to change the database casing, coz your programming language uses a different case.

So it will be nice to do it on ORM layer vs forcing it to change it at the database layer

[lffg]

Fair enough. I agree with your point of view.