Re: Testing database code in CPAN modules


Ron Savage <ron@xxxxxxxxxxxxx> writes:

> Joseph Brenner wrote:

>> [1] My "GraphViz::DBI::General" is a subclass of the existing
>> "GraphViz::DBI" which is intended to work with a wider range of
>> databases. In particular Postgresql, for which "GraphViz::DBI" is
>> pretty useless (it has no concept of schemas).  Also the original
>> module relies on a naming convention to find foreign keys, and I
>> prefer the DBI method "foreign_key_info" (even if it is labeled
>> "experimental").
>
> Is this of any relevance: http://savage.net.au/Ron/html/graphing-database-schema.html

Well, it's not *irrelevant*, but I see that you're take on the
problem just uses a *different* naming convention for foreign
keys:

The default implementation of GraphViz::DBI assumes that for a
column called t_id, then it is a foreign key if t is the name
of a table. This does not match my convention, so I wrote a
replacement for the sub, which uses my own table and column
naming convention to determine if a column is in fact a
foreign key. That convention is documented elsewhere. See
below for the link.

My take is that now that there's a DBI method that you can use to
get info about foreign keys, it's better to use that so the code
will work with any naming convention. And won't break if you
decide to deviate from the naming convention...

For example, I like the convention of using the table name as
the foreign key name (so my WHERE clauses look like
"person = person.id"). But what if I decide to create a
"freinds" table, that links together records in my person
table in pairs?

CREATE TABLE friends (
id SERIAL PRIMARY KEY,
person_1 REFERENCES person(id),
person_2 REFERENCES person(id)
);

Then I can't rigorously stick to the naming convention. I think
that's probably the case for most such naming conventions.

.