From the docs:

If the "employee" table has a column called "depart­
ment", and there is a table in the database also named
"department", then the "department" accessor for
Employee objects will return the object referred to by
the ID in that column. The mutator will also accept an
appropriate object (or ID).

UPDATE:
To elaborate more on that, offering the user the ability to specify that naming convention like so:

Class::Tables->dbh($dbh, {fk_prefix => 'fk_', fk_suffix => '_id'});
[download]

Other than that, it seems pretty cool. I have only tried fetching, no deletions or insertions, but i was impressed to see i could join across two tables with:

print $_->title, ': ', 
      $_->director_xref->director->name for Movie->search;
[download]

     movie
+-------+----+
| title | id | <=
+-------+----+

      director_xref
+-------+----+----------+
| movie | id | director | =>
+-------+----+----------+

  director
+----+------+
| id | name |
+----+------+

print $_->title, ': ', 
      $_->directors->name for Movie->search;
[download]

      director_xref
+----------+-------------+
| movie_id | director_id |
+----------+-------------+

All in all, very cool stuff. :)

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Is there anyway that you could allow the user to choose the naming convention of the foreign key? For example, i would prefer to use the name "deparment_id" instead.

Hmm, it seems like you are somehow seeing the old POD. Maybe your CPAN mirror has not gotten the latest (v0.23) that I uploaded about 6 hours before posting this announcement. In fact, an optional _id suffix is allowed on foreign and primary key column names now -- as well as intelligent matching with plural and singular column names and table names (using Lingua::EN::Inflect. Check out the POD on search.cpan.org (it's current there). In short, you can have a "departments" table and use "department_id" as a foreign key to it, etc.

but i haven't the foggiest clue how to cleanly implement/integrate that with what you have. A more valid gripe (i think) is to relax the condition that all tables must have a single primary key names 'id'. The reason is that a table like director_xref doesn't need it, instead it contains two primary keys (hence the suffix _xref). For example:

Right, I've thought a lot about entities and relationships, but many-to-many (with a mapping table) is something I'm not quite sure how to do. As you say, the mapping tables need not have a primary key ID column. Also, you might have extra information in the mapping table, as in the track number in a song-to-CD mapping table:

print $_->number, $_->song->name, $/ for $cd->tracks;
[download]

Doing away with an additional primary key on the mapping table would be pretty tricky currently, but I'm open to suggestions. If it's any consolation your primary key doesn't have to be named just id anymore, it can be tablename_id, etc, same as for foreign keys.

Anyway, thanks a lot for trying this out, and for your comments!

blokhead