Peter Rabbitson wrote:
Darren Duncan wrote:
Darren Duncan wrote:
http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/Manual/Example.pod
Generally speaking, I'm coming up with a number of clean-up ideas with
the above, where I mentioned one already, and here's another:
<snip>
Album is not used anywhere else from what I can tell, so for consistency
I would recommend 'CD' (and CDs have titles too, I am not sure I understand
your contrary argument).
As it is, after I wrote that, I changed my mind and decided that 'CD' was the
better term to normalize to rather than 'Album'. Partly because 'CD' was
already used 95% of the time, and because 'CD' looked visually better in the
context of 'Artist' and 'Track'; 'CD' looks very distinct from both while
'Album' looked too much like 'Artist'.
P.S. This scrutiny is coming up because I'm translating that Example to
another language, and while I'm generally trying to be faithful to the
original I am also doing some cleanups on the way; I hope this may
filter backwards.
I hope so too! Could you get a checkout of [1], and make changes as you go
along? Then simply send us an svn diff and we'll apply it (with possible
minor adjustments).
Thanks!
[1] http://dev.catalyst.perl.org/repos/bast/DBIx-Class/0.08/trunk/
Maybe I will. But in the meantime, here is my translation, now on CPAN, which
credits your original:
http://search.cpan.org/dist/Muldis-D-Manual/lib/Muldis/D/Manual/CD.pod
Besides the differences attributed to being in another language, I made these
changes of substance that I would recommend being in the original, if
appropriate or possible:
1. In the database schema, I added a unique key constraint on each of the
artist name, cd title, track title. While in reality there may be multiple
things with the same titles or names, your example inserting and querying code
made assumptions about these being distinct, and so I actually made the database
make them distinct so that the code would more likely work (or fail) correctly.
This might not be the best side to compromise in a real-life app (versus
properly accounting for duplicate names/etc), but it was the simplest thing for
the sake of the example code.
2. In the database schema, any column names having multiple words I separated
those with underscores for readability.
3. In the database schema, I adjusted some column names so that, across all 3
tables, any columns holding the same information have the same column names and
those having distinct information have distinct column names.
artist_id, artist_name
cd_id, artist_id, cd_title
track_id, cd_id, track_title
A benefit of this is that everything will just DWIM when you do queries with
natural inner joins, with no need to rename anything in queries, or explicitly
define join conditions, and all columns will have unique names, in most of the
usual cases, especially in all of your code examples.
4. I gave the tables plural names, adding 's'; the singular names are reserved
for talking about each individual row of a table. I recognize that DBIx::Class
may (I've heard) require the singular but the context of my translation doesn't.
5. In insertdb, I performed the inserts in bulk, and the whole collection as a
transaction, so it would succeed or noop as a unit.
6. In testdb, I added a sort of the titles being output, so that their display
order is more useful and consistent; your version would output them randomly in
general, like when you convert a hash to an array without sorting it.
7. In testdb, I added a transaction around the script so that its output would
have read consistency in case others might be modifying the database between its
component queries.
-- Darren Duncan
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
