Breaking change - Switch ORM naming strategy to CamelCase

[thetutlage]

This PR introduces a breaking change as it switches the naming strategy of ORM to camelcase. If this PR gets merged, this is how everything will be named.

• Given, you define the model properties in camelCase. Because, that is how we name properties and variables in JS.
• The column name for the database tables will be in snake_case (no change here).
• The column name for foreign keys and pivot tables will be in snake_case (no change here).
• The column name inside the serialized output, ie model.toJSON() will be camelCase. This is the breaking change

Why the change

The internal discussion was initiated by @RomainLanz to use camelCase for the serialized output as well. Models are usually (but not limited to) serialized when sending a JSON response for an HTTP API and a lot of the HTTP API consumers are frontend JavaScript clients which prefer camelCase over snake_case and hence they have to rename all these properties.

I believe Romain might have received this feedback from various channels and therefore he might be able to share more insights.

[RomainLanz]

I believe Romain might have received this feedback from various channels and therefore he might be able to share more insights.

Correct. It also creates some confusion with the validation system because your frontend receives snake_case and sends back snack_case, so validation must be snake_cased too.

Also, some API guidelines recommend using camelCase too, so there are no real conventions over what kind of casing you must use when creating an API.

In the end, it complicates everything mentally. I believe it is way better to stay in camelCase when we are outside of the database. Too much conversion creates confusion.