New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3.0 RFC: What is the benefit of table_names vs CamelCase and Singular/Plural for tables and Entities/Tables? #2767
Comments
Just close the ticket if I am totally off or wrong. |
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. |
I simply read through the docs and at least for cake bake you will need the Inflector, am I wrong? How does: I don't know much about the 3.0 ORM, if there are dependencies on the Singluar vs Plural-"thing" of the default association ( E.g. Table Names: E.g. naming the table exactly like the class extending And further: Why is there a difference between Singular and Plural for the Associations like There is even still this example in the current alpha docs:
... should be 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. |
It would be |
Ah... so then this example here is wrong: The rest makes no sense to you? If so, simply close it. |
I have fixed that manual example. For the rest i'll let Mark or Jose respond / close ticket as appropriate :) |
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) |
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. |
I never claimed to want singular table names, instead I |
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. |
Use? Yes. Promote? Not necessarily. |
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. |
I agree that it would make sense to use both PaselCased table and camelBacked field names for consistency. 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. |
If you still consider this worthwhile, maybe go for it in 3.1 or later. I will keep this closed. |
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
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
// differenceI 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?
The text was updated successfully, but these errors were encountered: