Skip to main content.
home | support | download

Back to List Archive

Using swish-e from *within* a database

From: David Fishburn <fishburn(at)not-real.ianywhere.com>
Date: Mon Jul 12 2004 - 18:59:43 GMT
I am using Swish-e 2.4.2.

I use Sybase Adaptive Server Anywhere (ASA) (www.ianywhere.com) as my
database.

One of the features it lacks is full text search capabilities.

>From the recent thread on PHP and MYSQL this morning it gave me an idea, so
I thought I would air it out looking for advice and comments.


ASA has the concept of external stored procedures.  So on Windows and Linux
you can create a DLL/SO with C/C++ code.  You can then call into functions
within this library the same way if they were internal stored procedures.

I have never used the C/C++ Swish-e interface so I am going to make some
guesses and assumptions.

>From a usage standpoint I was thinking (very quickly) along these lines.

CALL swishe_create_index( table_name, index_name, column_list );
-- This stored procedure would connect to the database and use the -S
interface to select out those columns and index them like a typical spider.
It would use the primary key of the table as the "name" of the document.

Then you could do something along these lines:
SELECT *
FROM table_name 
JOIN swishe_find( table_name, index_name, 'standard swishe search string' ) 
ON (the PKs of the tables)

You could possibly reindex daily, or one some schedule or event.

Unknowns:
1.  I am not sure what interfaces swish-e provides to retrieve its
configuration parameters.  I was thinking of creating a table and storing
each configuration item on a newline in the table.  The library can retrieve
these values from the database, or pass them in as a parameter.
2.  Does swish-e have to create a file for the index, or could you store the
result of the index in a LONG BINARY column in the database itself.  Then
when the search is done, you can just load the index from the database.
3.  If 2 does not work, then we can store the absolute path name to the
file, and go that route.
4.  I assume we would have a separate file/index per table, but that depends
on your implementation.

Has anyone attempted something along these lines before?

Comments welcome.

Thanks,
Dave
Received on Mon Jul 12 12:00:39 2004