[Dbix-class] Branch for supporting column attributes checked in

[John Napiorkowski]

--- Matt S Trout <dbix-class at trout.me.uk> wrote:

> John Napiorkowski wrote:
> > --- Matt S Trout <dbix-class at trout.me.uk> wrote:
>
> >>>> Also, I see absolutely no reason to pollute the
> >>>> column_info with DB-specific 
> >>>> crud - why can't Storage::DBI::Pg detect 
> >>>> $source->column_info($col)->{data_type} being
> >>>> 'bytea' and DWIM?
> >>> $source->column_info($col)->{data_type} would

[snip]

Getting closer I think...

I checked in a version of this this branch that
creates a new function in DBIx::Class::Storage::DBI
like:

sub bind_attribute_by_data_type {
    return;
}

Which I am overriding in the database specific storage
objects, like for Postgres in
DBIx::Class::Storage::DBI::Pg I have...

sub bind_attribute_by_data_type {
  my ($self,$data_type) = @_;

  my $bind_attributes = {
	bytea => { pg_type => DBD::Pg::PG_BYTEA },
  };
 
  if( defined $bind_attributes->{$data_type} ) {
    return $bind_attributes->{$data_type}
  }
  else {
    return;
  }
}

The idea being that we only map the bind attributes
that need it, like the troublesome blog types. 
Otherwise the database planners seem to do fine so why
mess with a good thing (unless someone knows why and
corrects my ignorance).

I can't see a way around having a manual mapping,
since this give me the best control.  I really don't
want something like:

 my $attr = { "pg_$data_type" =>
DBD::Pg::PG_$data_type};

Which I'm not even sure would work now that I'm
looking at it :)

I've found from poking around inside the DBD's for
different databases that the attribute constants that
get defined are not always as consistent as you might
hope.  Plus it's won't handle user create types in
postgres, etc.  Anyway it can be difference for the
different databases.

Right now in the Pg one I just have a dumb lookup
hash; is there a preferred way we do this kind of
thing?  I looked around the packages and didn't see
anything similar I could use as a model.

Also, still need someone with Oracle to assist
creating this for the oracle storage driver.

One last bit about testing, is it okay that my tests
for this require Postgresql and just skip if
postgresql isn't installed?  I really don't see any
way to test without that, since this patch is for
database specific stuff. I mean it should really have
a database specific test for each database that
defines this function.

Thoughts about how I can make this more right would be
greatly appreciated.  I've been using this in my new
project for about two weeks and it seems pretty
stable, even been uploading huge mpegs right into the
database without any trouble.  I didn't notice any
trouble with regular usage.

Thanks!
John


 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com