[Catalyst] RFC: Would this be useful to anyone?

Mario Minati mario.minati at googlemail.com
Tue Mar 20 19:48:04 GMT 2007


Am Dienstag 20 März 2007 16:50 schrieb John Napiorkowski:
> I have a version of Catalyst::Model::DBIC::Schema where I hacked in some
> code to automatically look at the query string and perform some limits and
> sorting.  Basically if it sees a something like:
>
> ...?[table].page=1&[table].max-results=10&[table].order-by=[column].[direct
>ion]
>
> It will automatically create a new resultset object with the correct
> limits.  It can also do (very unoptimized) searches with something like
>
> ...?[table].search=[text to search in the table]
>
> I'm adding in the ability to set a start and end range, as well with
> something like
>
> ...?[table].start-index=10&[table].end-index=100
>
> I was wondering if the community thinks this could be useful, or if it
> would be more useful in some other state.  I know that this kind of
> resultset limiting is something I do all the time and I assume it's the
> case for others.
>
> Right now I have this integrated with my Schema classes, as I mentioned
> above, but I am not sure it's the best thing to do.  Although it will DWIM
> when I do $c->Model('table') it doesn't help me if that resultset has one
> to many relationships that also need to be limited.  So I have this also as
> a DBIC component in order to handle this for me.
>
> I was thinking perhaps we'd prefer to have this as a separate model that
> you'd pass a resultset and a $c->request to to get the limited resultset,
> instead of so much magic:
>
> my $fullrs = $c->Model('Table');
> $c->forward($c->Model('LimitResultSet'), [$fullrs, $c->request]);
>
> ## Now $fullrs has been limited as described above
>
> I was thinking to use $c->forward because I tend to use forward when I am
> implementing a command or pipeline style design pattern, but this could
> also easily be:
>
> my $fullrs = $c->Model('Table');
>
> my $pagedrs = $c->Model('LimitResultSet')->build($fullrs, $c->request)
>
>
> Or something similar If people preferred:
>
> Then again maybe it would just be better to keep it as a raw DBIC
> component:
>
> my $pagedrs = $fullrs->search_by_query($c->request);
>
> This would have the benefit of working reasonally well will people using
> CGI.pm outside of Catalyst.  This is sort of what I am doing now, I have a
> component and my hacked Catalyst model calls it to save myself a bit of
> trouble.  The only
>
>
> Any thoughts?

The idea is quite fascinating.

I would go for a solution where you make a subclass in the DBIC namespace to 
avoid any function calls at all. You would just need one connect function to 
give the $c handle to the DBIC subclass, but maybe you can patch the Model 
function to autoconnect the model with $c if the model isa 'DBIC::subclass'.

If that would take to much freedom the search_by_query would be my way.

>
> BTW, one thing that is making this hard for me to make cross database is
> that in the full text search Postgres requires ILIKE to make the search
> case insensitive, unlike ever other database.  Right now in my DBIC code I
> do:
>
>         foreach my $keyword ( split(/\s/, $value) )
>         {
>             my @keywords = split(',', $keyword);
>
>             push @array, [
>
>                 -or => [ {$column => {'ILIKE' => [ map { '%'.$_.'%' }
> @keywords ]} } ], ];
>         }
>
> to build the correct data structure for searching.  Does anyone out there
> know if there is a neat cross database way to do this, or do I need to
> explicitly check for Postgres and use ILIKE instead of like?

I don't know any.

Greets,
Mario Minati



More information about the Catalyst mailing list