Re: [Dbix-class] DBIx::Class::Index::Simple
On Wed, 2 Apr 2008, 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?
No you don't, the SQLT producers unique-ify them for you.
Jess
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
Re: [Dbix-class] DBIx::Class::Index::Simple
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/] );
Ash expressed the same concern and here is what I said:
ribasushi ash: I was thinking to make add_index a method at first, however it
does not go along with the philosophy of dbic (as far as I see it)
ribasushi -set_primary_key, -add_unique_constraint - they all have some
meaning for DBIC itself
ribasushi where as an index is meaningless, and only SQLT would care about it
ribasushi I figured I'll add it as an attribute, just like is_foreign_key is
a column attribute
ash what about multi-col indexs tho?
ribasushi you still use the hook
ribasushi that's why the Simple
Additionally such functionality used to exist but was pulled away in r3815
(trunk), to give way to sqlt_deploy_hook.
Should it get reinstated?
+=head1 USAGE NOTES
+
+The module adds indexes by declaring a version of the Csqlt_deploy_hook
method. If you
+want to use this component together with your own Csqlt_deploy_hook, you
need add an
+explicit inherited method call to your version:
+
+sub sqlt_deploy_hook {
+my ($self, $sqlt_table) = @_;
+
+do your stuff
+
+$self-next::method ($sqlt_table); #call sqlt_deploy_hook from
Index::Simple
+}
This chunk of docs should probably live in a more general place. It's
not just users of your extension that need to know this.
Suggestions?
Peter
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
Re: [Dbix-class] DBIx::Class::Index::Simple
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
___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
