On Sat, Nov 08, 2008 at 10:31:52AM -0800, Ovid wrote:
> --- On Fri, 7/11/08, Eden Cardim <[EMAIL PROTECTED]> wrote:
>
> > <[EMAIL PROTECTED]> wrote:
> > > Because we use the resultset methods heavily,
> > particularly the pager. We'd have to find a minimal
> > subset of behavior we'd be willing to support and wrap
> > that in our our resultset wrapper. Yuck.
> >
> > I think you need DBIx::Class::Schema::RestrictWithObject
>
> We already looked at that. As far as we can tell, it's just syntactic sugar
> for extra "where" conditions. It doesn't satisfy our requirement because we
> need to filter on conditions which cannot be expressed via SQL.
Then I don't understand how the pager is any use - it really wants you to
be able to COUNT()
There's no reason you can't do $rs->set_cache([ <arbitrary perl> ]) though.
The other approach would be to create a custom class/object with an
inflate_result method that skips the nonexistant objects - the return value
of inflate_result is actually in list context and DBIC will keep fetching
rows off the DB until it gives it a row back (and correctly stash >1 row
object returned).
I'd be happy to help further with either of these for payment in the form of
a cookbook entry :)
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/
_______________________________________________
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]
