[ic] Calling all search gurus

interchange-users@interchange.redhat.com interchange-users@interchange.redhat.com
Thu Aug 9 18:26:00 2001


On Thu, Aug 09, 2001 at 12:38:30PM -0700, Ed LaFrance wrote:
> Hi all -
> 
> Using IC 4.6.5 with MySQL.  Need to do a form-based search, something like 
> this:
> 
> mv_search_field="field1,field2,field3,field4"
> mv_searchspec="foo"
> 
> mv_search_field="field5"
> mv_searchspec="1"
> 
> I need to find all products which have /foo/ in any of the corresponding 
> fields, AND do not have '1' in the other field.  I thought this would be a 
> simple coordinated search:
> 
> <input type=hidden name=mv_searchtype value=db>
> <input type=hidden name=mv_coordinate value=yes>
> 
> <input type=hidden name=mv_search_field value="field1,field2,field3,field4">
> <input type=text name=mv_searchspec value="foo">
> <input type=hidden name=mv_column_op value=rm>
> <input type=hidden name=mv_numeric value=0>
> 
> <input type=hidden name=mv_search_field value="field5">
> <input type=hidden name=mv_searchspec value=1>
> <input type=hidden name=mv_column_op value="!=">
> <input type=hidden name=mv_numeric value=1>
> 
> ..but it does not work.  The problem is the multiple search fields in the 
> first group - if I search just one field, it works fine - multiple fields 
> completely break the search.  Somehow I need to tell IC that "foo" in 
> field1 OR field2 OR ... etc. is acceptable for the first group - it appears 
> to be applying 'AND' logic to the list of fields instead.
> 
> Perhaps this can be done with an SQL statement? But I would rather not rely 
> on searching products.txt, I prefer to search the db directly.
> 

Leaving aside length of fields, indexing and so forth....  It sounds
like an expensive and time consuming search.

What we've started doing of late is dumping sql db to a formatted 
*.tab field and indexing that with glimpse.  Then we log the queries
and cache the result sets.  (Those get periodically wiped; next step 
is to trigger rebuild of common queries.)  The preformatting cuts
down processing/rendering/JOIN time.

If a result set exists, use it, else build it.  You could preformat 
your dumps anyway you want, as final output or an intermediate.  Then 
it is a relatively small perl script to pull in the result.

Someone else might know more than I about developments in indexing
text in RDBMS.  It's my understanding that it's just not one of the
things a typical RDBMS is good at.

cfm


> Thanks in advance for any suggestions!
> 
> - Ed L.
> 
> 
> 
> ===============================================================
> New Media E.M.S.               Software Solutions for Business
> 463 Main St., Suite D          eCommerce | Consulting | Hosting
> Placerville, CA  95667         edl@newmediaems.com
> (530) 622-9421                 http://www.newmediaems.com
> (866) 519-4680 Toll-Free       (530) 622-9426 Fax
> ===============================================================
> 
> _______________________________________________
> interchange-users mailing list
> interchange-users@interchange.redhat.com
> http://interchange.redhat.com/mailman/listinfo/interchange-users

-- 

Christopher F. Miller, Publisher                               cfm@maine.com
MaineStreet Communications, Inc           208 Portland Road, Gray, ME  04039
1.207.657.5078                                         http://www.maine.com/
Content/site management, online commerce, internet integration, Debian linux