[Dbix-class] ping 'from' attribute doc author: you need to fix them

[Toby Corkindale]

On Wed, May 10, 2006 at 04:55:12PM +0100, Matt S Trout wrote:
> Toby Corkindale wrote:
> > Hi,
> > just following on from a discussion on IRC yesterday..
> > I was asking about why a 'from' clause in a search method of mine was
> > causing D::C to die with an error.*
> > The answer given was that I shouldn't be using 'from' at all, as I wasn't a
> > developer, and only people who were willing to read and grok the source code
> > should touch that attribute.
> 
> That was largely because I was grumpy and had already said "you don't 
> need this, you should be using 'join' which will work fine" three times 
> and been ignored.

You really don't know me well - I really hate not understanding something, and
if I'm doing something wrong (with 'from=>') then I want to know what it is.

It's not neccessary, but I *should* be able to use 'from' to do what I was
doing. Even if I didn't need it then, I will probably need it in the future.
(Either that, or I have to break out the Real SQL (tm) to do anything complex..
which sort of defeats the point.)

> Fortunately, "either read the entire source for half of DBIC or stop 
> asking questions about from" got you to read the docs and figure out how 
> to do it properly before I got *really* mad :)

Yeah, which was that "single()" doesn't support attributes, something which is
easy overlooked in the docs, since it says for single that it is "like a search
that automatically expands just the first result".

> Sometimes the answer I give is a solution to a meatware problem, not a 
> software problem :)

I'd suggest in this case it was more avoiding the issue than fixing it :)
(please note smiley)
There's still a problem with the 'from' attribute, after all. The examples
might work, but the schema for writing the syntax doesn't match the behaviour.

> > I don't have enough D::C-fu to know myself.
> > One thing that definately doesn't seem to work as specified is the
> > optionality of the nested join block.
> 
> The examples presented are ripped straight out of the tests, and as such 
> are pretty definitely ok.
> 
> I think the mistake is simply that the *contents* of the nested join 
> block are optional (if you don't have a nested join) but the arrayref 
> itself, while it might be empty, isn't.

WHen I was experimenting with it, that didn't appear to be the case.
The addition of an empty [] arrayref merely caused a different error to turn up
(complaining about lack of contents of above array) I think..

> Can whoever originally wrote this step up and correct it please?

And perhaps add another couple of tests to your test suite?

CHeers,
Toby

-- 
Turning and turning in the widening gyre/The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold/Mere anarchy is loosed upon the world
(gpg --keyserver www.co.uk.pgp.net --recv-key B1CCF88E)