in reply to Class::Tables released

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).
Request:
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.

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]
for example, would be ultra nice and seems doable. They would default to the empty string, so that if not specified, the result would be the name of the table being referenced.

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]
(and the tables) 
     movie
+-------+----+
| title | id | <=
+-------+----+

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

  director
+----+------+
| id | name |
+----+------+
However, while explicitly calling upon director_xref has some merits, it would be nice to be able to just say: 
print $_->title, ': ', 
      $_->directors->name for Movie->search;

[download]
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: 
      director_xref
+----------+-------------+
| movie_id | director_id |
+----------+-------------+

All in all, very cool stuff. :)

jeffa

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)

Replies are listed 'Best First'.
Re: Re: Class::Tables released
by blokhead (Monsignor) on Dec 21, 2003 at 04:57 UTC
    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

[reply]
[d/l]

In Section Perl News