[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