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

Tue Jul 26 19:03:28 EDT 2005

On 7/26/05, David Glasser <glasser at bestpractical.com> wrote:
> ...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).
First of all, there is no consistency in the SB constructors: Record
constructor takes named handle, while SB.pm takes one arg handle!

Context object? I don't much problems with current situation, I write
SB extension and do nothing with constructor, it takes handle like in
the core. If end user wants context, current user or whatever he wants
he override constructor or _Init.
I want only one thing - API consistency! SB has big problem - you
can't use it if you read docs only, you have to read code also, at
least first lines of the subs to see how args handling happens.

I don't mind against Context object feature if it would be done smart.

> 
> 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.
standards is a weak side of SB.

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

> 
> * 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?
Don't see much usage of this.
I have one idea: use the same low-level method for update multiple
columns and create new record then you can subclass this low level
method.
Or may be Hook::LexWrap for pre/post hooks?

> 
> * 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
Yeah, update multiple columns at once would be good.

> 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.
IMHO save call would make SB harder to use.

> 
> * 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.
+1

> 
> * Rethink the case-sensitivity of queries stuff, and the LIKE %foo%
> stuff.
About case-sensetivity in searches:
1) all this is specific for DB handle
2) you can have three situations: 1) DB can be only case-sensetive, 2)
only case-insensetive and 3) supports both. If you have 3 variants and
methods returns only true or false then you need at least two methods
to report which variant is supported. Or you can use fact that perl
support trinary return values: undef, false and true.
IMHO it's not good style when we make difference between undef and false...
ah and I forgot that if DB supports both variants then you should know
which is default.
As I think, we need two methods: IsCaseSensetive and
CanChangeSensetivity. Methods names are subject to change.

> 
> * 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?
Different situations require different solutions. if you run your code
under mod_perl then you want precompile almost all methods in init
script, but when you write small interactive script then you may need
faster start up.

> 
> Just some things worth considering.
Moi 2 kopeiki :)

> 
> --dave
>    Code Monkey, Best Practical Solutions
> --
> David Glasser | glasser at bestpractical.com
> 
> 
> 
> 
> 
> _______________________________________________
> SearchBuilder-devel mailing list
> SearchBuilder-devel at bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/searchbuilder-devel
> 

-- 
Best regards, Ruslan.