I have a Maypole-based, not-quite-finished interface to a library
database that I compiled a few years ago
(http://dynamic.ropine.com/library/). The database schema does not have
Maypole-friendly field names: e.g., the primary key of the "authors"
table is "author_id", not "id". I handled this by telling Class::DBI
what the primary key field was: "__PACKAGE__->columns(id => 'title_id');".
I don't remember all the other deviations and workarounds--it's been a
few months since I last looked at this code--but I remember (a) I made
it work; (b) working around the naming convention was a bit more of a
nuisance than I would have liked.
Obviously, I could have renamed all the objects in my database to
conform to Maypole's expectations, and made my life easier. However, in
my experience, the person writing the front end of a database-backed
Web application often does not have any control over the schema used for
the database. Given that fact, this argument over how tables and fields
*should* be named seems kind of beside the point.
-- Reporter: "Why do you think bin Laden has not been caught?" President Bush: "Because he's hiding." // seth gordon // sethg at ropine.com // http://dynamic.ropine.com/yo/ //_______________________________________________ maypole mailing list maypole at lists.netthink.co.uk http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:58 GMT