darren at darrenduncan
May 28, 2009, 1:39 PM
Post #2 of 3
(337 views)
Permalink
|
hkclark[at]gmail.com wrote:
> A new version of Catalyst::Manual has been posted to CPAN. Although
> we don't yet have a lot of Catalyst 5.80-specific material just yet
> (there is some initial information at
> http://search.cpan.org/perldoc?Catalyst::Manual::CatalystAndMoose --
> Please send in any contributions you might have!), I have tested
> everything in the tutorial against 5.8004, so we have bumped the
> version number of Catalyst::Manual to 5.8XXX as well
Thanks. As someone who intends to begin using Catalyst with the 5.8+ series,
its nice to have documentation focused on the new best practices.
> But the important changes in this release include:
>
> * Plural DB table names are now singular. Many thanks to
> Kiffin Gish (krg) for all the help on that effort!
This may be bike-shedding and no big deal, but I think this was better the old
way. A table represents info on a collection of items, and is best named after
what the collection as a whole is, such as 'books', 'authors', 'book_authors',
etc, same as how you'd name an array variable in Perl. Instead, 'book' or
'author' etc is best used as the name of a variable containing a single row from
said table, such as with "for my $book (@books) {...}".
Now more important than that however, I recommend updating the examples so that
all of the id columns are named 'foo_id' consistently rather than 'foo_id' in
some places and 'id' in others, where it makes sense. In this case, 'book'
should have 'book_id' and 'author' should have 'author_id'. One reason for this
is that you can then easily do a natural join between the 3 tables, or between
any applicable 2 tables, and the rows would match up as they should, and result
columns would have distinct names, whereas with your current naming you'd have
to write an explicit join condition to make them match up and explicit column
renames to identify which 'id' you're looking at in a resultset or view. The
benefits of such a naming scheme go beyond that, and would seem to outweigh any
benefits of naming them all 'id'. The point is it is more natural and a best
readability and maintainability practice for like things to have like names and
unlike things to have different names.
-- Darren Duncan
_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
|
