[Dbix-class] seeming error in Manual's CD db example

[Darren Duncan]

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