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

[Brandon Black]

On 1/9/06, Brandon Black <blblack at gmail.com> wrote:
> 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.
>

I've committed changes to the trunk for relationship testing for
mysql, pg, and db2.  There's a new test-controlling environment
variable for the relationship testing for mysql, MYSQL_TEST_INNODB,
since not everyone's mysql installation might have the neccesary
innodb support.  I also committed the change from "comment" to
"Comment" for now.  You can checkout trunk via:

svn checkout http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class-Loader

or grab a snapshot I just made from:

http://www.dtmf.com/DBIx-Class-Loader.tgz

-- Brandon