search

PhilWaldmann / openrecord

Make ORMs great again!
https://openrecord.js.org
MIT License
486 stars 38 forks source link

Thoughts on snake_case vs camelCase #72

Closed arthurfranca closed 6 years ago

arthurfranca commented 6 years ago

Javascript style guide says we should use camelCase for identifiers. When using javascript both on back-end and on front-end it would be great to use only camelCase so it wouldn't be needed to transform keys when sending/receiving data from back-end to front-end.

So, i.e., maybe it's good to accept not only user_id (convention on RoR world and kind of a convention on SQL) but also userId. Also on things such as User.where({login_not: null}) make it accept accept loginNot too.

The same for all table names and colum names, which should be double quoted on all SQL commands (or else it is considered case insensitive). I think knex already double quotes everything as default so it wouldn't be a problem.

It would be great to have it as a config parameter. Sequelize has it as underscored: false(default)/true.

Another option is to at least have an alias for attributes and relations, accessing both as, i.e., user.preferred_colors and user.preferredColors while keeping everything snake_case on database.

PhilWaldmann commented 6 years ago

Yes! That's something I wanted to to for a long time, but never found the time.
The same problem occurs with GraphQL (camelCase convention).

I think I'll add a conversion function to convert field names from the database to the model representation. With build in defaults for snake and camel case.

Thanks, Philipp

PhilWaldmann commented 6 years ago

version 2.2 now has two new store options externalAttributeName and internalAttributeName. See the docs or the test case for more info.