[rt-devel] DBIx::Searchbuilder woes

[Michael Grubb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

   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.

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.

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

- -Michael

On Friday 23 August 2002 05:14 am, Robie Basak wrote:
> On Thu, 2002-08-22 at 19:28, Michael Grubb wrote:
>
> [...]
>
> > Just remember that Limit method calls really just append 'AND|OR Field =
> > VALUE' to the WHERE clause of a query.  and of course you can do things
> > such as Like by setting the OPERATOR key in the parameter hash to 'LIKE'
>
> One question here though; what about brackets? As in if I wanted to
> do x OR (y AND z) then does it get interpreted as (x OR y) AND z? Or am
> I just expected to know the SQL well enough to write the query in the
> correct order?
>
> The "correct" way of doing this would be to define the ENTRYAGGREGATOR
> as (say) postfix, so that to do the former you'd call x, y, z, AND, OR
> and the latter x, y, OR z, AND (reverse-polish) or something similarly
> well-defined. But the current API doesn't give that flexibility.
>
> So I'm suggesting something like:
>
> $MyTickets->LimitRequestor(VALUE =>
> $session{'CurrentUser'}->EmailAddress);
> $MyTickets->LimitCc(VALUE => $session{'CurrentUser'}->EmailAddress);
> $MyTickets->Limit(ENTRYAGGREGATOR => 'OR');
>
> Or, for my x, y and z examples above, for (x or (y and z)):
>
> $MyTickets->LimitX(...);
> $MyTickets->LimitY(...);
> $MyTickets->LimitZ(...);
> $MyTickets->Limit(ENTRYAGGREGATOR => 'AND');
> $MyTickets->Limit(ENTRYAGGREGATOR => 'OR');
>
> or for ((x or y) and z):
> $MyTickets->LimitX(...);
> $MyTickets->LimitY(...);
> $MyTickets->Limit(ENTRYAGGREGATOR => 'OR');
> $MyTickets->LimitZ(...);
> $MyTickets->Limit(ENTRYAGGREGATOR => 'AND');
>
> This is a non-ambiguous, fairly standard and widespread way of doing it,
> and the way I think it "should" work. I'd say that this should be a new
> method of doing it in terms of the API (which will require changes to
> the code, obviously) and the old method should be deprecated.
>
> What do people think of this?
>
> > You are very right about the documentation of DBIx::SearchBuilder though.
> > I built an application unrelated to RT on top of it.  I think it is a
> > great library, but it is a bear to learn.  The way I figured it out was
> > by examining nearly all of the RT modules and examing the
> > DBIx::SearchBuilder code indepth, however this is not so bad because
> > Jesse codes better than most perl programmers.
>
> I agree with you completely; Jesse's code is great :)
>
> I've made a huge number of modifications to RT, all of which I've only
> been able to do because I can grok the code very easily and very
> quickly.
>
> Unfortunately most of them have at least some element of hack and so I'm
> reluctant to contribute them, but I am busy cleaning things up so
> hopefully things which I think might be useful to others will filter
> through :)
>
> Robie.
> _______________________________________________
> rt-devel mailing list
> rt-devel at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9ZlsBAUDeVla85B8RAszcAKCTpYP9vhX1XgmOJPVq7Qe/yCyEgwCfekf1
YiCuPYubzG/76KqPbF2egKM=
=lv/A
-----END PGP SIGNATURE-----