[DBIx-Class-Devel] Pull Request: topic/docs-pod-inherit

[Brendan Byrd]

On Tue, Dec 11, 2012 at 2:22 PM, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
>
> Because it is *not* a relationship attribute. It is an *argument* to
> find() (on which update_or_create, find_or_create, find_or_new and
> the *_related siblings are based). It is not something that search()
> ever looks at. Hence the "special" status.

Fair enough.  I'll implement as you suggested earlier.

> The simple answer without going into details is: resultset chaining
> only works reliably and predictably because of its simple rules:
> conditions/joinspecs are always additive, everything else is always
> an override (last one wins). Because of this property default_attrs
> are not well suite for conditions - one can not shake them off. Nor
> are they well suited for other attrs like order_by - one can not shake
> it off without supplying a *different* order.
>
> ...
>
> In my personal opinion this is a wild goose chase - there is no
> tangible benefit to implementing something along these lines. One can
> always write *multiple* methods on the resultet in question to achieve
> the same effect. It is cleaner, better self-documenting, and much less
> intrusive. The effort to implement your idea reliably on the other
> hand is *very* substantial. Nevertheless - if you still feel strongly
> about the need for such a (mis)feature - draw up a larger proposal. I
> just wanted to warn you ahead of time that it will be hard to convince
> the core-devs to go forward with something like this.

Nah, I don't have a strong need for it, but I just wanted some basic
understanding on the problems around it.  Some of this helps in the
CAVEAT writing, too.

It's a shame that it's problematic to implement, as it would be nice
to have some sort of virtual_view type View class that doesn't require
knowledge of SQL to implement.  I will also redirect users to the View
docs as an alternative to rs_attr, since many of the asks around that
could be solved via View.

> I was thinking a document along the lines of:
>
> =item update
>
> L<DBIx::Class::CDBICompat::Triggers/update>
> ...
> L<DBIx::Class::Ordered/update>

So, what I was saying + an extra feature in P:I to document every
method down the chain.  Of course, we're going into non-Inherit
territory at this point, so that's worth another module for that.

Frankly, I'd like to convert P:I to a Pod::Weaver plugin
(Pod::Weaver::Section::InheritedMethods), and start some sort of
branch to start using P:W in DBIC.  That's a different project for
another day...

-- 
Brendan Byrd <Perl at ResonatorSoft.org>
Brendan Byrd <BBYRD at CPAN.org>