[rt-devel] DBIx::Searchbuilder woes

[Robie Basak]

On Fri, 2002-08-23 at 16:55, Michael Grubb wrote:
> Well, RPN sounds like a good idea, but here is the issues.
>    1) It would take quite a bit of code rewriting to support it,
>        because internally DBIx::SearchBuilder builds the query as you call
>        methods.  So to keep track of everything till the end would require at
>        least an array.  And then you have the issue that when you call limit
>        in this manner you may be left with an incomplete __or__ invalid query,
>        until you make a call to limit with ENTRYAGGREGATOR.

As for rewriting; yes, it would :)

But at the moment all I can see is how limited the search functionality
is, and I can't see any other way of improving it.

At the moment ENTRYAGGREGATOR defaults to 'OR' (am I right?). So
wouldn't it be possible to make a query valid just by adding a number of
ORs to the end? I'm not sure that there will be a backwards
compatibility issue; inclusion of an ENTRYAGGREGATOR in the same call as
a query could just be a shortcut of adding it to the end, so the calls:
    LimitA
    LimitB(ENTRYAGGREGATOR => OR)
would be expanded to:
    LimitA
    LimitB
    Limit(ENTRYAGGREGATOR => OR)
which is the same thing (the same for AND).

Or have I missed something? As far as I can see adding the necessary ORs
to the end would result in exactly the same query as it does now,
regardless of the existing queries already being used (as in, complete
backwards compatiblity). But it is late, so I'll happily accept an
example of where it isn't the case :)

>    2) It IMO is not the most intuitive way of looking at things,  forgive me
>        if I admit my ignorance here, but I've always had somewhat of a mental
>        block with RPN, it just doesn't come naturually to me.

Fair enough; but what is the alternative? At the moment, unless there's
something in the API I don't understand, the Limit function is _very_
limited, since you can only do ANDs and ORs without any brackets.

If the interface were _exactly_ the same as before, except that you
could do RPN as well if you wanted to (I think this is the case with my
proposal), then is that an issue?

> After briefly looking through the code, there is a SUBCLAUSE option
> to Limit, I've never used this option so I'm not entirely sure as to it's 
> purpose, and initially looking at the code it is not to me _entirely_ obvious 
> as to what it is doing.

*looks*

It looks to me like it lets you add an arbitrary chunk of SQL to go
after the WHERE which is ANDed with everything the function puts in
already. So it does let you do what you want, but reverts you to writing
SQL, which is the whole point of the thing.

> But that's just my opinion...I could be wrong.

Me, too :)

Robie.