Re: Updated Limit Patch for C::DBI & C::DBI::MySQL

[prev] [thread] [next] [Date index for 2004/07/28]

I haven't looked carefully at the search code before posting this, but
what about something along these lines...

Have modules register a "search_handler" which _do_search() can then
pass the various fragments of the SQL to ("SELECT * FROM", "WHERE
.."), along with the $search_opts hash.  The search handlers modify
the fragments and pass them back.  Search goes down the chain until
all registered search_handlers are done.

This would allow for CDBI::Plugin modules to add features to search(),
as well as specific DB subclasses and CDBI could ignore everything in
$search_opts it doesn't know about.  Or maybe have the classes remove
items from $search_opts that they deal with and throw an exception if
there's any left at the end of the chain.

Todd
--
Todd Holbrook
Systems Consultant
Simon Fraser University Library


On Wed, 28 Jul 2004 17:38:16 +0100, Tony Bowden <tony-cdbitalk@xxxxx.xxx> wrote:
> On Wed, Jul 28, 2004 at 11:25:20AM -0500, jason scott gessner wrote:
> > Basically, there is a new method added to C::DBI called
> > _make_limit_frag, which returns ''
> 
> Is there something more generic we're missing here? I'd rather
> Class::DBI didn't need to know about LIMIT at all, but still had some
> sort of hook here that means any database subclass could add anything
> that it supported. I really don't want to have to keep adding things for
> all the extensions that each database provides...
> 
> Tony
>