[Dbix-class] DBIx::Class::Index::Simple

[Mark Lawrence]

On Wed Apr 02, 2008 at 08:50:02AM +0200, Peter Rabbitson wrote:
> Mark Lawrence wrote:
> >On Tue Apr 01, 2008 at 08:35:38PM -0500, Jonathan Rockway wrote:
> >>* On Tue, Apr 01 2008, Peter Rabbitson wrote:
> >>
> >>> __PACKAGE__->add_columns(
> >>>   id => { data_type => 'integer', is_auto_increment => 1 },
> >>>   starts_at => { data_type => 'datetime' },
> >>>-  created_on => { data_type => 'timestamp' }
> >>>+  created_on => { data_type => 'timestamp', index_as => 
> >>>'created_test_simple_idx' }
> >>> );
> >>The problem with this syntax is that you can only index one column.  Why
> >>not do:
> >>
> >>  __PACKAGE__->add_index( idx_foo_bar => [qw/foo bar/] );
> >
> >How often do you need to know the name of an index? Why not go one
> >simpler and do:
> >
> >    __PACKAGE__->add_index(qw/foo bar/);
> >
> >Which could return the autogenerated name of the index. If you need the
> >name at a later (more dynamic stage perhaps) then maybe expose the
> >name generating method as well.
> >
> 
> When you generate several indexes per table, you need to be in full control 
> of naming so no clashes will occur. In the above example what would be the 
> index name? foo_bar? what if foo_bar is an indexed column too?

Of all the schemas I've worked on I've never had that name clash, but
then I also find it a bit silly to have a column (indexed) named foo_bar
if you are going to index foo and bar. My autogenerating
index name code tends to prefix the table name, working around similarly
named columns in different tables.

A better suggestion then is to make the simple case easy, and the
complicated possible, al la this pseudo code:

    sub add_named_index { # usage: name => qw/columns/
        'CREATE INDEX '. (shift) .' ON '.......'. join(',', @_);
    }

    sub add_index { # usage: qw/columns/
        my $name = 'idx_'. $table_name .'_'. join('_', @_);
        $self->add_named_index($name, @_);
    }

Mark.
-- 
Mark Lawrence