[Dbix-class] Restricting Result Sets

Ovid publiustemp-dbic at yahoo.com
Sun Nov 9 12:59:13 GMT 2008


--- On Sat, 8/11/08, Jess Robinson <castaway at desert-island.me.uk> wrote:
 
> This part of the description makes it sound like your
> constraints/filter 
> criteria are all SQL-based.. That essentially you need a
> more complex 
> search that ends up similar to (psuedo sql):
> 
> select * from Identifier
> where type='pid' and value=$pid
>     and (exists select pid from brand
>          or exists select pid from series
>          or exists select pid from episodes)
> 
> - which will only return used ones.

This sounds great, but I deliberately oversimplified the problem to get to its core.  In reality, there are many different types of IDs (different supplies often offer different IDs) and many of the objects have several ID types (because different suppliers may offer the same data) and they don't always have the same type name in the target tables as they do in the identifier table (that's a refactoring issue we need to resolve).

As a result, this is a much harder problem to solve, but we might be able to come up with something with proper introspection.  Since we're using Moose more often, this might prove to be a viable long-term solution.  I'll have to look at this.

> As for doing this on an rs where the condition is NOT
> database based, all 
> I can think of is: add cache => 1 to the attrs, force
> the rs to fill the 
> cache by calling ->all on it or something, then
> post-manipulate the cache 
> contents on the $rs object.
> 
> ->count doesnt use the cache that I know of, tho one
> could override it to.

Wouldn't this break paging, too?

Cheers,
Ovid



More information about the DBIx-Class mailing list