[SearchBuilder-devel] Things I'd like to see changed in SearchBuilder

David Glasser glasser at bestpractical.com
Tue Jul 26 10:16:26 EDT 2005


...or Jifty::DBI, as it were.

There are some things about SB that I love:

* The search building!  Incremental LIMIT creation is awesome!
* The fact that it actually *has* intelligent collection objects  
(other ORDBMS don't)

There are some things that are kind of annoying though:

* I like the fact that when we use SB we put things in it like  
current user support and other "context awareness.  But unfortunately  
this means that the various different apps we have that use SB have  
entirely different calling conventions for Record->new and Collection- 
 >new.  This means it's basically impossible to write code (like SB  
extensions) that actually creates new objects or collections.  The  
main solution that I see here is to introduce the concept of a  
Jifty::DBI::Context object, which carries an entirely application- 
defined payload.  Whenever code inside Record, Collection, or a  
subclass of it needs to create a new object, it simply passes on its  
own Context object.  Application code most likely will be keeping  
around a "current context" object that it can pass into most of its - 
 >new calls (like we currently do with a current user object).

In the end it would be no more complicated than the invocations of  
"current user" everywhere, but would be much more standardized and  
usable by non-application code.

* We need to have validation and canonicalization support be used  
*everywhere*.

* Somehow deal with the fact that columns can be set by either  
set_foo methods *or* by create... validation and canonicalization  
methods can deal with that of course, but for things like "do X after  
the foo column is set" overriding set_foo just doesn't cut it.   
Perhaps there should be a specific "after-setting-foo" hook that is  
called?

* In a similar vein, there are times where I want to set a bunch of  
columns at the same time, and I want (a) nothing to happen unless all  
of the columns I'm changing validate and (b) the equivalent of the  
"after-setting-foo" hooks to only fire after all of the columns have  
been changed.  (And while this is much less important, it would be  
nice if SB could be smart and use a single UPDATE statement to update  
all of the columns.)  I don't *think* that SB current has a bulk  
update feature like that, though maybe I'm confused.  The two obvious  
ways of doing this, I think, are:
   * Just provide a multi-column "set" method that does what I say.   
Fully backwards-compatible, though any code that chooses to use a  
series of set_foo calls would still have the two problems that this  
would be trying to fix.
   * Make a *major* change to the way Records work, and make them  
entirely transactional -- set_foo methods don't actually do anything  
to the database, and you explicitly ->save once you're ready.  This  
also lets you put all your error handling in one place.  (This is the  
ActiveRecord way.  It seems to work, though I'm not sure whether or  
not it's better than the other option.

* While we're doing an API redesign, I'd like a better evaluation of  
what methods fall into the vague categories of "public", "protected",  
and "private".  Sure, this is Perl, and we don't need to be fascists  
about it, but we should figure out which things really are meant to  
be called from application code, which are meant to be called from  
subclasses, and which just aren't meant to be called outside of the  
file.

* Rethink the case-sensitivity of queries stuff, and the LIKE %foo%  
stuff.

* What should we do with Schemas?  What works about them and what  
doesn't?  Is "return a big hash" the best plan?  Should we do  
something more like Class::DBI where code is called at package load  
time which generates a whole bunch of functions, instead of using  
AUTOLOAD? Or is that what breaks Module::Refresh?

Just some things worth considering.

--dave
   Code Monkey, Best Practical Solutions
-- 
David Glasser | glasser at bestpractical.com







More information about the SearchBuilder-devel mailing list