3.0 RFC: What is the benefit of table_names vs CamelCase and Singular/Plural for tables and Entities/Tables?

[ionas]

What is the benefit of supporting Inflector, CamelCasing and Singular vs Plural on the ORM level (really fine with the view level)?

Table names: movies, ratings, comments, tags

    public function initialize(Array $config) {
        $this->belongsTo('Movies');
        $this->hasOne('Rating');
        $this->hasMany('Comments');
        $this->belongsToMany('Tags');
    }

Edit: Source http://book.cakephp.org/3.0/en/appendices/orm-migration.html#associations-no-longer-defined-as-properties

VS

Table names: Movies, Ratings, Comments, Tags // difference

    public function initialize(Array $config) {
        $this->belongsTo('Movies');
        $this->hasOne('Ratings'); // difference
        $this->hasMany('Comments');
        $this->belongsToMany('Tags');
    }

I do understand that it is slightly less nice to read, especially now that the 3.0 ORM tries to make a meaningful difference between HasMany/BelongsToMany and HasOne/BelongsTo (Plural vs Singular)... but do you really think it is worth it having the Inflector as a dependency on the ORM for 3.0?

• I assume PostgreSQL and MSSQL support case sensitive/upper case table names.
• As for a migration path one can set public $useTable or similar.
• Removing this feature could also yield minimal performance benefits.

[ionas]

Just close the ticket if I am totally off or wrong.

[markstory]

Joining relations together is always plural. They never use singular names. Inflector isn't a hard dependency, but you need to explicitly configure all the property names and options.

Edit: Perhaps I'm not understanding your issue here though.

[ionas]

I simply read through the docs and at least for cake bake you will need the Inflector, am I wrong? How does: $this->hasOne('Rating'); get to come to life?

I don't know much about the 3.0 ORM, if there are dependencies on the Singluar vs Plural-"thing" of the default association (hasMany, belongsTo, etc.) names for the Controller- or View-Domain. If not I still think being consistent would help future users as well as upgraders.

E.g. Table Names:
class Post -> table Post
class ProductPage -> table ProductPage
class Group HABTM class User -> table Groups_Users // join convention
Migration path for existing apps: within initialize() -> $this->table('groups_users');

E.g. naming the table exactly like the class extending App\Model\Table. Why is there a difference, now that there is an Entity class and a Table class between the class name and the table name e.g. Post vs posts. Not that I care, but I have even been mocked by Yii users for this feature in Cake2, e.g. not the whole world does it like this ;-).

And further: Why is there a difference between Singular and Plural for the Associations like $this->hasMany('Comments'); vs $this->hasOne('Rating'); instead of $this->hasOne('Ratings');

There is even still this example in the current alpha docs:

Users hasOne Addresses  addresses.user_id
Doctors hasOne Mentors  mentors.doctor_id

... should be Doctor?s hasOne Mentor?
Source http://book.cakephp.org/3.0/en/orm/table-objects.html

I do see, that it reads a bit better but overall consistency means less to explain and less tiny conventions to learn e.g. less errors.

[ADmad]

How does: $this->hasOne('Rating'); get to come to life?

It would be $this->hasOne('Ratings'); ie. Plural form same as table name, no inflection. In the manual eg. too it's hasOne('Addresses').

[ionas]

Ah... so then this example here is wrong:
http://book.cakephp.org/3.0/en/appendices/orm-migration.html#associations-no-longer-defined-as-properties

The rest makes no sense to you? If so, simply close it.

[ADmad]

I have fixed that manual example.

For the rest i'll let Mark or Jose respond / close ticket as appropriate :)

[lorenzo]

Is there anything else to address here? I'm not sure I'm following what other problem there is after the documentation was fixed (thanks @ADmad)

[markstory]

I don't see how having the table name be the singular form makes anything simpler. I think it will make things harder, both from a migration prespective and an implementation pov. Both User, Group and Order are reserved words in many databases. Using these as table names requires identifier quoting and makes querying on a prompt much harder.

[ionas]

I never claimed to want singular table names, instead I
a.) promoted to use plural throughout the whole stack which is already the case (sorry, miss-understanding the migration docs)
and b.) to use upper case table names so that the database table names match the php table class names.
Closing.

[markstory]

It is possible to use Pascal cased table names, would you also use camelBacked field names? Both are possible now, but not the default behaviour.

[ionas]

Use? Yes. Promote? Not necessarily.
My argument was to keep things the same across the framework wherever possible reducing conventions to learn. Thus the idea was to have Pascal-cased table names.
Do you think camelBacked field names have any benefits in FormHelper, Controller Context or Model Context?

[markstory]

I don't think there is any benefit to camelBacked fields beyond consistency. If you had pascalcased table names it would be strange to have snake cased column names.

I think the migration hurdles make switching to pascal case for tables less attractive. I find the table/class convention is a simple one and unlikely to be source if slowness.

[dereuromark]

I agree that it would make sense to use both PaselCased table and camelBacked field names for consistency.
But since migration is already quite the beast, this would mainly be useful for new projects where you can start from scratch.

It would not be hard to write a migration script to change the casing for the db, but changing the code around it as well will prove way more difficult I assume.

[ionas]

If you still consider this worthwhile, maybe go for it in 3.1 or later. I will keep this closed.