[Dbix-class] DBIx::Class::Loader::mysql - bug(?)

[Brandon Black]

On 1/9/06, Brandon Black <blblack at gmail.com> wrote:
> On 1/9/06, Alan Humphrey <alan.humphrey at comcast.net> wrote:
> >
> >
> >
> > I'm using MySQL 5.  I'd like Loader to load my relationships.  There is a
> > problem in DBIx::Class::Loader::mysql :
> >
> >   my $comment = $sth->fetchrow_hashref->{comment} || '';
> >
> >
> >
> >
> > should be
> >
> >   my $comment = $sth->fetchrow_hashref->{Comment} || '';
> >
> >
> >
> >
> > note the capital 'C'.  Does anyone know whether this is a bug in
> > Loader::mysql or a change in MySQL 5?  The MySQL docs make it sound like
> > it's always been 'Comment'.
>
> There's a DBI attribute related to this:
>
> "FetchHashKeyName" (string, inherited) - The "FetchHashKeyName"
> attribute is used to specify whether the fetchrow_hashref() method
> should perform case conversion on the field names used for the hash
> keys. For historical reasons it defaults to '"NAME"' but it is
> recommended to set it to '"NAME_lc"' (convert to lower case) or
> '"NAME_uc"' (convert to upper case) according to your preference.  It
> can only be set for driver and database handles. For statement handles
> the value is frozen when prepare() is called.
>
> I would assume {comment} worked for whoever first implemented
> DBIx::Class::Loader::mysql, and most likely a number of other people
> (I'm pretty sure I've done some tests of relationship loading w/ mysql
> that worked fine as well).  I'm wondering if there's a descrepancy in
> the default setting of this attribute in various versions of
> DBD::mysql or something.  Worst case we can just test for both
> capitalizations.  I'll look in more detail this evening when I have
> access to a mysql installation.
>

Nothing like a little time playing with mysql to remind me how much I
love Postgres :)

Even in 4.x, with recent DBI and DBD::mysql it's coming up as
"Comment" for me.  Since only InnoDB tables even support foreign key
references (and even then, "references foo (bar)" is silently ignored
as an inline column constraint, it can only be successfully specified
via a seperate "foreign key" statement at the end), and since the
DBIx::Class::Loader tests do not test relationships (except for
SQLite), I can only assume it has just always been broken this way and
nobody else has ever used it successfully.

Does anyone else have a counter-example where "SHOW TABLE STATUS"
returns a column named "comment" instead of "Comment"?

We can either patch it to just "Comment", or accept both if there's an
example of the current (broken?) expected behavior in the wild
somewhere.  In any case I'll patch in some vendor-specific
relationship testing if I can, so that we can have a hope of catching
more things like this.

-- Brandon