[Dbix-class] better HTML-Widget integration

Matt S Trout dbix-class at trout.me.uk
Fri Mar 24 15:25:12 CET 2006


Carl Franks wrote:
> I've started work on extra HTML-Widget constraints at
> http://dev.catalyst.perl.org/repos/Catalyst/trunk/HTML-Widget-Constraint-MySQL/
> 
> At the moment, the intended use is something like:
>     $w->constraint( 'MySQL::VARCHAR', 'name' )->length( 30 );
> 
> What I'd like is a better front-end, so that the user's code isn't
> mysql specific, and can use other database's constraints, if they're
> available.
> 
> I'm imagining something like this:
>     $w->constraint( 'DBColumn', 'name' )->class( 'UserClass' );
> and if the field-name isn't the same as the column name:
>     $w->constraint( 'DBColumn', 'name' )->class( 'UserClass'
> )->column( 'username' );
> 
> What this would require though, is an API in DBIx-Class to retrieve
> the database type:
> 'mysql', 'Pg', etc
> and the column datatype:
> 'INT', 'VARCHAR(10)', 'ENUM('a', 'b')
> from the *database*

my $info = $result_source->column_info($colname);

$info->{data_type};
$info->{size};

> I don't want the DBIx-Class user to have to put these values into their classes.
> Each database backend should be able to get this info from the database.
> Yes, it'll be very database-specific, but that's the job of each
> constraint's database-backend to know what to do with it.

DBIx-Class already does this. If you don't specify data type, size etc. it 
does its best to load 'em off the db the first time column_info is called.

The usual reason for specifying the type information at the DBIC level is that 
you want to be able to use the SQLT support to generate your CREATE TABLE 
statements (and later manage upgrades seamlessly etc.) - it's not compulsory 
in the slightest.

> It needs to be very database specific. For example,
> HTML-Widget-Constraint-MySQL can currently validate string length
> based on byte length or character length, by knowing the mysql-server
> version. This is the sort of specificity I'd need for the constraints
> to be really useful.
> 
> Does anyone have any opinions on this suggestion?
> Does anyone have any ideas for how the API might look?
> Is anyone willing to work on this?


-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +



More information about the Dbix-class mailing list