Re: search() without search criteria

[prev] [thread] [next] [Date index for 2005/04/29]

> On Fri, Apr 29, 2005 at 05:53:00PM +0100, Will Hawes wrote:
> > A patch to search() (or rather, =5Fdo=5Fsearch()) would be a better
> > solution. The ability to pass an empty hash to search() is logical a=
nd
>=20
> Why=3F=20
>=20
> Surely a search with no search criteria is no longer a search=3F
>=20
> Tony

I would argue that it is logical, yes. Certainly in the context of a sea=
rch done using SQL. A SELECT statement without a WHERE clause is still a=
 SELECT statement. Just as a hash is still described as such even if it =
contains zero elements.

If anything, CDBI has an illogical approach to retrieving data because i=
t uses three separate methods, search(), retrieve() and retrieve=5Fall()=
, to do the job of SQL's SELECT statement.

Ultimately "retrieve" and "retrieve=5Fall" are just specific types of se=
arch. The former for a specific record in a table, the latter for all re=
cords. So these two statements would be the same:

@cds =3D CD->retrieve=5Fall({});
@cds =3D CD->search({});

Using the latter method, a "search or browse" function can be made simpl=
er. No need to modify your base class to have artificial columns and pas=
s artificial stuff like "{1 =3D> 1}" to search(). No need to test whethe=
r criteria were specified and if not, call to retrieve=5Fall() instead. =
You just pass your user's search criteria directly to search() - if no c=
riteria are specified, it just returns all records.

And since search() supports a second parameter, sorting/paging/LIMITing =
functionality would be easier to implement, either in subclasses or CDBI=
 itself, because the code would only have to worry about calling a singl=
e sub. No more need for retrieve=5Fall=5Fsorted=5Fby.

I'm not suggesting scrapping any of the existing code in CDBI. This chan=
ge should not break any existing code whatsoever. But it would make CDBI=
 simpler and easier to use.

Regards

WH