[Need Advice] Thinking about snake_case/camelCase

[kapv89]

The change to eloquent which made $model->someProperty access $model->some_property messed up my plans for a camelCase database .. need some advice on how you guys handle the context switch in an app. I can change this in my base model, but i feel that'd be going a bit too far.

There's request-input, validation-rules, custom queries etc .. i suddenly feel like i lack a process to handle the context change (since i was using camelCase everywhere till now, and that was quite consistent)

[kapv89]

gonna write a thin layer over illuminate/database to make it convention free

[kfriend]

One possible solution could be to pass the key name to a new method within the getAttribute() and setAttribute() methods, instead of using snake_case() function. Something like translateAttribute(). By default, this method would just snake case the key name. However, it would allow overriding on a per model basis.

[kapv89]

@kwoodfriend .. that still leaves the timestamps snake_case, figure if i want consistency, why not just go all the way / but gonna spend some time thinking about sticking with snake_case too

[kapv89]

I am reopening this issue .. its bugging me like hell, and i don't want to code a wrapper over eloquent db layer just to get over it

relationships are defined in camelCase, database fields are in snake_case, so need to use that in db operations, eloquent accepts camelCase fields, input fields can be camelCase if they are snakeCase, you gotta take care of relations or define relations in snake_case and keep your input in snake_case but defining only relations as snake_case looks like an oddity in code Honestly, i find the "snake_cased_db" convention -very- useless validation rules can be written in snake_case, but internally are converted back to camel and iirc, you gotta extend validator using CamelCase get my beef with the useless convention ?

[pleinechope]

I'm in the same case. I'm not the only one using the DB so i can't change it at all. For now the only way is to develop/maintain a layer over illuminate/database. It's so shame, before https://github.com/laravel/framework/commit/d6316f09f59df1d0003c319a424d9dfc7b353381 everything was good.

[kapv89]

If laravel doesn't go full camelCase or "any case you want", I'd really like to have some established convention to know when to use snake_case and when to use camel_case across a project. I don't like thinking about it whenever i am dealing with input-data, database-queries, caching, creating services, relationships etc

[taylorotwell]

I think it's fine how it is. Eloquent required camel_case in L3, and I don't think it's super practical to have people convert their entire databases to camelCase for L4. Remembering when to use what is pretty easy:

• Class names are study case and methods are camel case (PSR-1).
• Eloquent attributes can be accessed using either snake or camel case, but database tables and columns are snake case.
• Configuration options, language lines, and view names are snake case and use "dot" syntax.
• Global functions are snake case per PHP convention.
• Input can be whatever you want.

That's really all there is to it.

[kapv89]

if l4 goes "caseless", people porting from l3 can use snake_case in their db layer. Even when serializing data, relations suddenly go camelCase when rest of the stuff is snake_cased. l4 already breaks a lot of bc, what's one more. Having a simple standard across the "logic-heavy" areas of code eases stuff up a bit. And thanks for the guidelines :)

[kapv89]

oh and relationship methods gotta be defined in snake_case now