NAME

DBIx::FullTextSearch - MySQL をストレージとしてドキュメントのインデクスをつくる


SYNOPSIS

    use DBIx::FullTextSearch;
    use DBI;
    # データベースに接続 (通常のDBI)
    my $dbh = DBI->connect('dbi:mysql:database', 'user', 'passwd');

    # ストップリストの作成
    my $sl = DBIx::FullTextSearch::StopList->create_default($dbh, 'sl_en', 'English');

    # デフォルトの english ストップリストと english ステマでインデクスを作成
    my $fts = DBIx::FullTextSearch->create($dbh, 'fts_web_1',
                frontend => 'string', backend => 'blob',
                stoplist => 'sl_en', stemmer => 'en-us');
    # あるいは既存のものを開く
    # my $fts = DBIx::FullTextSearch->open($dbh, 'fts_web_1');

    # ドキュメントをインデクスする
    $fts->index_document('krtek', 'krtek leze pod zemi');
    $fts->index_document('jezek', 'Jezek ma ostre bodliny.');

    # マッチの検索
    my @docs = $fts->contains('foo');
    my @docs = $fts->econtains('+foo', '-Bar');
    my @docs = $fts->search('+foo -Bar');


DESCRIPTION

DBIx::FullTextSearch is a flexible solution for indexing contents of documents. It uses the MySQL database to store the information about words and documents and provides Perl interface for indexing new documents, making changes and searching for matches. For DBIx::FullTextSearch, a document is nearly anything -- Perl scalar, file, Web document, database field.

DBIx::FullTextSearch はドキュメントの内容をインデクスするためのフレキ シブルなソリューションです。このモジュールは MySQL データベースを使っ て単語とドキュメントの情報を格納し、新たにドキュメントのインデックスを 作成したり、変更したり、マッチを検索するための Perl インタフェースを提 供します。DBix::FullTextSearch においては、ドキュメントはほぼなんでも OKです -- Perl スカラ、ファイル、Web 文書、データベースフィールドなど。

The basic style of interface is shown above. What you need is a MySQL database and a DBI with DBD::mysql. Then you create a DBIx::FullTextSearch index -- a set of tables that maintain all necessary information. Once created it can be accessed many times, either for updating the index (adding documents) or searching.

基本的なインタフェースのスタイルは上記の通りです。必要なのは MySQL デー タベースと DBI, DBD::mysql です。次に DBIx::FullTextSearch イン デクスをつくります。このインデクスは、すべての必要な情報をメンテナンス するテーブルによって構成されます。一度つくれば、インデクスの更新 (ドキュ メントの追加)や検索用に、何度でもアクセスすることができます。

DBIx::FullTextSearch uses one basic table to store parameters of the index. Second table is used to store the actual information about documents and words, and depending on the type of the index (specified during index creation) there may be more tables to store additional information (like conversion from external string names (eg. URL's) to internal numeric form). For a user, these internal thingies and internal behaviour of the index are not important. The important part is the API, the methods to index document and ask questions about words in documents. However, certain understanding of how it all works may be usefull when you are deciding if this module is for you and what type of index will best suit your needs.

DBIx::FullTextSearch はまずベースのテーブルにインデクスのパラメータを 格納します。2つめのテーブルに、ドキュメントと単語、またインデクスのタ イプ(インデクスの作成時に指定)によって、他の情報を格納するためのテーブ ルをいくつか使用します(外部の文字列(URLなど)から内部の数値への変換表な ど)。ユーザにとっては、こうした内部のものごとやインデクスの振る舞いは 重要ではありません。重要なのはAPI、つまりドキュメントのインデクス生成 やドキュメント内の単語へのクエリを行うメソッドです。しかし、全体として どのように動作するのかをある程度知っておくことは、このモジュールを使用 すべきか決定したり、どのタイプのインデクスが最適かを選択する際にきっと 有益でしょう。


Frontends


フロントエンド

From the user, application point of view, the DBIx::FullTextSearch index stores documents that are named in a certain way, allows adding new documents, and provides methods to ask: ``give me list of names of documents that contain this list of words''. The DBIx::FullTextSearch index doesn't store the documents itself. Instead, it stores information about words in the documents in such a structured way that it makes easy and fast to look up what documents contain certain words and return names of the documents.

ユーザアプリケーションの視点からみると、DBIx::FullTextSearch のインデ クスは、何らかの形で名前づけられたドキュメントを格納し、新たにドキュメ ントを追加でき、``この単語リストを含むドキュメントの名前を教えて''といっ たクエリを行うメソッドを提供します。DBIx::FullTextSearch のインデクス は、文書自身は格納しません。代わりに、ドキュメント内の単語についての情 報を構造化して保持し、特定の単語を含んだドキュメントを検索して、ドキュ メント名を返すことを高速に行えるようにしています。

DBIx::FullTextSearch provides a couple of predefined frontend classes that specify various types of documents (and the way they relate to their names).

DBIx::FullTextSearch は定義済みのフロントエンドクラスをいくつか提供し ており、それぞれにドキュメントタイプ(とそれがどのように名前と関連づい ているか)が指定されています。

default

By default, user specifies the integer number of the document and the content (body) of the document. The code would for example read

デフォルトでは、ユーザはドキュメントナンバーとドキュメントの中身(ボディ) を指定します。

        $fts->index_document(53, 'zastavujeme vyplaty vkladu');

and DBIx::FullTextSearch will remember that the document 53 contains three words. When looking for all documents containing word (string) vklad, a call

のようなコードを例にすると、DBIx::FullTextSearch はドキュメント53は3つ の単語を含んでいることを覚えておきます。単語(文字列) vklad を含むすべ てのドキュメントを検索する際には、

        my @docs = $fts->contains('vklad*');

would return numbers of all documents containing words starting with 'vklad', 53 among them.

とすると、'vklad' からはじまる単語を含むすべてのドキュメントナンバー、 ここでは 53 を返します。

So here it's user's responsibility to maintain a relation between the document numbers and their content, to know that a document 53 is about vklady. Perhaps the documents are already stored somewhere and have unique numeric id.

よってここではドキュメントナンバーと中身のリレーション、つまりドキュメ ント53が vklady についてのものである関係をメンテナンスするのはユーザの 責任です。ドキュメントはすでに他の場所で格納され、ユニークな数値のIDを 持っているような場合です。

Note that the numeric id must be no larger than 2^doc_id_bits.

数値IDは 2^doc_id_bits より大きくてはいけないことに注意してください。

string

Frontend string allows the user to specify the names of the documents as strings, instead of numbers. Still the user has to specify both the name of the document and the content:

フロントエンド string を使うと、ユーザはドキュメントの名前を数値で はなく、文字列で指定することができます。ここでもユーザはドキュメント名 と中身を指定する必要があります。

        $fts->index_document('foobar',
                        'the quick brown fox jumped over lazy dog!');

After that,

そうしたら、

        $fts->contains('dog')

will return 'foobar' as one of the names of documents with word 'dog' in it.

は 'dog' を含むドキュメントの名前として 'foobar' を返します。

file

To index files, use the frontend file. Here the content of the document is clearly the content of the file specified by the filename, so in a call to index_document, only the name is needed -- the content of the file is read by the DBIx::FullTextSearch transparently:

ファイルをインデクスするには、フロントエンド file を使います。ここ ではドキュメントの中身は明らかにファイル名によって指定されるファイルの 中身ですから、index_document を呼ぶ際には名前だけしか必要ありません。 ファイルの中身の読み込みは DBIx::FullTextSearch によって透過的に行われ ます。

        $fts->index_document('/usr/doc/FAQ/Linux-FAQ');
        my @files = $fts->contains('penguin');
url

Web document can be indexed by the frontend url. DBIx::FullTextSearch uses LWP to get the document and then parses it normally:

フロントエンド url でウェブ文書のインデクスが行えます。 DBIx::FullTextSearch は LWP を使ってドキュメントを取得し、通常通り パースします:

        $fts->index_document('http://www.perl.com/');

Note that the HTML tags themselves are indexed along with the text.

HTML タグもテキスト同様にインデクスされることに注意してください。

table

You can have a DBIx::FullTextSearch index that indexes char or blob fields in MySQL table. Since MySQL doesn't support triggers, you have to call the index_document method of DBIx::FullTextSearch any time something changes in the table. So the sequence probably will be

DBIx::FullTextSearch を使って MySQL テーブルの char あるいは blob の フィールドにインデクスをはることができます。MySQL はトリガをサポートし ていないため、DBIx::FullTextSearch の index_document メソッドをテー ブルが変更する度に呼び出す必要があります。順序としては、

        $dbh->do('insert into the_table (id, data, other_fields)
                values (?, ?, ?)', {}, $name, $data, $date_or_something);
        $fts->index_document($name);

のようになるでしょう。

When calling contains, the id (name) of the record will be returned. If the id in the_table is numeric, it's directly used as the internal numeric id, otherwise a string's way of converting the id to numeric form is used.

contains を呼ぶと、レコードの id (名前) が返ります。the_table の id が数値なら、内部の数値id としてそのまま使用できますし、そうでなければ string と同様の方法で id から数値に変換されます。

When creating this index, you'll have to pass it three additionial options, table_name, column_name, and column_id_name. You may use the optional column_process option to pre-process data in the specified columns.

このインデクスをつくる際には、3つのオプション table_name, column_name, column_id_name を指定する必要があります。オプション として、指定されたカラムのデータに整形処理を行うための column_process オプションも用意されています。

The structure of DBIx::FullTextSearch is very flexible and adding new frontend (what will be indexed) is very easy.

DBIx::FullTextSearch の構造はとてもフレキシブルなので、新たなフロント エンド(なにがインデクスされるか)を追加するのはとても簡単です。


Backends


バックエンド

While frontend specifies what is indexed and how the user sees the collection of documents, backend is about low level database way of actually storing the information in the tables. Three types are available:

フロントエンドがなにをインデクスするか、またユーザがドキュメントの集合 をどのように扱うかを指定するのに対し、バックエンドはローレベルで実際に どのようにテーブルへ情報を格納するかを定義します。3つのタイプが利用可 能です。

blob

For each word, a blob holding list of all documents containing that word is stored in the table, with the count (number of occurencies) associated with each document number. That makes it for very compact storage. Since the document names (for example URL) are internally converted to numbers, storing and fetching the data is fast. However, updating the information is very slow, since information concerning one document is spread across all table, without any direct database access. Updating a document (or merely reindexing it) requires update of all blobs, which is slow.

各単語について、blob はその単語を含むすべてのドキュメントのリストを、 ドキュメントナンバーと出現回数とともにテーブルに保持します。ストレージ はとてもコンパクトになります。ドキュメント名(たとえばURL)は内部で数値 に変換されるので、データの格納や取得は高速です。しかし、ドキュメントの 更新(あるいは単なる再インデクス)はすべての blob を更新する必要があり、 遅いです。

The list of documents is stored sorted by document name so that fetching an information about a document for one word is relatively easy, still a need to update (or at least scan) all records in the table makes this storage unsuitable for collections of documents that often change.

ドキュメントのリストはドキュメント名でソートされ、1つの単語のドキュメ ントの情報を取得するのは比較的容易になっていますが、テーブルの全レコー ドを更新 (あるいはスキャン) する必要があるため、頻繁に更新されるドキュ メントコレクションにはこの格納方法は向いていないでしょう。

column

The column backend stores a word/document pair in database fields, indexing both, thus allowing both fast retrieval and updates -- it's easy to delete all records describing one document and insert new ones. However, the database indexes that have to be maintained are large.

column バックエンドはデータベースのフィールドに単語/ドキュメントの ペアを格納し、両方をインデクスするので、取得も更新も高速になっています。 つまり、あるドキュメントに関するレコードをすべて削除したり、新たに追加 したりするのは簡単です。しかし、メンテナンスするテーブルは大きくなりま す。

Both blob and column backends only store a count -- number of occurencies of the word in the document (and even this can be switched off, yielding just a yes/no information about the word's presence). This allows questions like

blobcokumn はともにカウント、つまりドキュメント内の単語の出 現回数しか保存しません(またこれをオフにして、単語が出現するか否かの情 報だけにすることもできます)。よって以下のようなクエリ

        all documents containing words 'voda' or 'Mattoni'
                but not a word 'kyselka'

        'voda' か 'Mattoni' を含むが 'kyselka' を含まないドキュメント

but you cannot ask whether a document contains a phrase 'kyselka Mattoni' because such information is not maintained by these types of backends.

を実行できますが、あるドキュメントが 'kyselka Mattoni' というフレーズ を含んでいるかどうかを知ることはできません。そうした情報はこれらのバッ クエンドではメンテナンスされていないためです。

phrase

To allow phrase matching, a phrase backend is available. For each word and document number it stores a blob of lists of positions of the word in the document. A query

フレーズマッチングを実現するのに、phrase バックエンドを利用できます。 単語とドキュメントナンバーごとに、ドキュメント内の出現個所のリストを blob で保存します。

        $fts->contains('kyselk* Mattoni');

then only returns those documents (document names/numbers) where word kyselka (or kyselky, or so) is just before word Mattoni.

というクエリは、単語 kyselka (あるいは kyselky など) が単語 Mattoni の 直前にあるドキュメント (ドキュメント名/ナンバー) しか返しません。


Mixing frontends and backends


フロントエンドとバックエンドの融合

Any frontend can be used with any backend in one DBIx::FullTextSearch index. You can index Web documents with url frontend and phrase backend to be able to find phrases in the documents. And you can use the default, number based document scheme with blob backend to use the disk space as efficiently as possible -- this is usefull for example for mailing-list archives, where we need to index huge number of documents that do not change at all.

ひとつの DBIx::FullTextSearch インデクスで、任意のフロントエンドとバッ クエンドを使用できます。フロントエンド url で Web 文書をインデクス して、phrase バックエンドでドキュメント内のフレーズを検索るというわ けです。デフォルトにすれば、ナンバーベースのドキュメントスキームと、 blob バックエンドによってディスクスペースをなるべく効率的に使えます。 たとえばメーリングリストのアーカイブのように、あまり変化しない膨大な数 のドキュメントをインデクスする必要があるときには便利でしょう。

Finding optimal combination is very important and may require some analysis of the document collection and manipulation, as well as the speed and storage requirements. Benchmarking on actual target platform is very useful during the design phase.

最適な組合せを見付けるのはとても重要ですが、ドキュメントのコレクション と操作についての分析や、速度やストレージに関する要件を必要とします。設 計フェーズにおいて実際のプラットフォーム上でベンチマークをしてみると大 変有益です。


METHODS

The following methods are available on the user side as DBIx::FullTextSearch API.

DBIx::FullTextSearch API として、以下のメソッドがユーザサイドで利用可能です。

create

        my $fts = DBIx::FullTextSearch->create($dbh, $index_name, %opts);

The class method create creates index of given name (the name of the index is the name of its basic parameter table) and all necessary tables, returns an object -- newly created index. The options that may be specified after the index name define the frontend and backend types, storage parameters (how many bits for what values), etc. See below for list of create options and discussion of their use.

クラスメソッド create は、指定した名前(インデクスの名前はベースとな るパラメータテーブルの名前です)のインデクスと必要なテーブルをすべて作 成し、オブジェクト、つまり新しく作られたインデクスを返します。インデク ス名の後に指定されるオプションは、フロントエンドとバックエンドのタイプ、 ストレージのパラメータ (値ごとのビット数) などを定義します。create の オプションリストやその使用方法については、以下を参照してください。

open

        my $fts = DBIx::FullTextSearch->open($dbh, $index_name);

Opens and returns object, accessing specifies DBIx::FullTextSearch index. Since all the index parameters and information are stored in the $index_name table (including names of all other needed tables), the database handler and the name of the parameter table are the only needed arguments.

指定された DBIx::FullTextSearch のオブジェクトを返します。インデクスの パラメータはすべて(他に必要なテーブル名も含め) $index_name テーブル に保存されていますので、データベースハンドラとパラメータテーブルの名前 のみが必要です。

index_document

        $fts->index_document(45, 'Sleva pri nakupu stribra.');
        $fts->index_document('http://www.mozilla.org/');
        $fts->index_document('http://www.mozilla.org/','This is the mozilla web site');

For the default and string frontends, two arguments are expected -- the name (number or string) of the document and its content. For file, url, and table frontends the content is optional. Any content that you pass will be appended to the content from the file, URL, or database table.

defaultstring フロントエンドの場合、2つの引数が求められます -- ドキュメント名 (数値もしくは文字列) とその中身です。file, url, table フロントエンドの場合は中身は省略可能です。中身を何か 渡すと、そのファイル、URL、データベーステーブルから取得した中身にアペ ンドされます。

delete_document

        $fts->delete_document('http://www.mozilla.org/');

Removes information about document from the index. Note that for blob backend this is very time consuming process.

インデクスからドキュメントに関する情報を削除します。blob バックエン ドの場合これは非常に時間がかかるプロセスであることに注意してください。

contains

        my @docs = $fts->contains('sleva', 'strib*');

Returns list of names (numbers or strings, depending on the frontend) of documents that contain some of specified words.

指定された単語のいくつかを含むドキュメント名のリスト (フロントエンド次 第で、数値もしくは文字列となる)を返します。

econtains

        my @docs = $fts->econtains('foo', '+bar*', '-koo');

Econtains stands for extended contains and allows words to be prefixed by plus or minus signs to specify that the word must or mustn't be present in the document for it to match.

econatins は extended contains を意味し、プラスやマイナスを先頭につけ ることによって、マッチすべきドキュメントに素の単語が出現するかしないか を指定できます。

search

 my @docs = $fts->search(qq{+"this is a phrase" -koo +bar foo});

This is a wrapper to econtains which takes a user input string and parses it into can-include, must-include, and must-not-include words and phrases.

econtains へのラッパで、ユーザの入力文字列を受け取って、含んでもよい/ 含まなくてはならない/含んではならない単語とフレーズにパースします。

contains_hashref, econtains_hashref, search_hashref

Similar to contains, econtains and search, only instead of list of document names, these methods return a hash reference to a hash where keys are the document names and values are the number of occurencies of the words.

contains, econtains, search に似ていますが、ドキュメント名の リストではなく、キーがドキュメント名で値が単語のドキュメント内出現回数 となるハッシュリファレンスのリストを返します。

drop

Removes all tables associated with the index, including the base parameter table. Effectivelly destroying the index form the database.

インデクスに関連するテーブルを、ベースパラメータテーブルを含め、すべて 削除します。データベースからインデクスを効率的に削除できます。

 $fts->drop;
empty

Emptys the index so you can reindex the data.

インデクスを空にしてデータを再インデクスできるようにします。

 $fts->empty;


INDEX OPTIONS

Here we list the options that may be passed to create method. These allow to specify the style and storage parameters in great detail.

create メソッドに渡すオプションのリストです。スタイルやストレージの パラメータを細かく指定することができます。

backend

The backend type, default blob, possible values blob, column and phrase (see above for explanation).

バックエンドのタイプ。デフォルトは blob で、とりうる値は blob, column, phrase (詳細な説明は上部参照)

frontend

The frontend type. The default frontend requires the user to specify numeric id of the document together with the content of the document, other possible values are string, file and url (see above for more info).

フロントエンドのタイプ。default フロントエンドはユーザがドキュメン トの数値 id と中身を指定する必要がある。ほかにとりうる値は string, file, url, table (詳細な説明は上記参照)。

word_length

Maximum length of words that may be indexed, default 30.

インデクスされる単語の最大長。デフォルトは 30。

data_table

Name of the table where the actual data about word/document relation is stored. By default, the name of the index (of the base table) with _data suffix is used.

実際の単語/ドキュメントリレーションを格納するテーブル名。デフォルトで は、インデクス名 (ベーステーブル名) の後ろに _data をくっつけたもの。

name_length

Any frontend that uses strings as names of documents needs to maintain a conversion table from these names to internal integer ids. This value specifies maximum length of these string names (URLs, file names, ...).

ドキュメント名に文字列を使うフロントエンドでは、これらの名前から整数値 の id への変換表をメンテナンスする必要があります。この値はこうした文字 列 (URL, ファイル名) の最大長を指定します。

blob_direct_fetch

Only for blob backend. When looking for information about specific document in the list stored in the blob, the blob backend uses division of interval to find the correct place in the blob. When the interval gets equal or shorter that this value, all values are fetched from the database and the final search is done in Perl code sequentially.

blob バックエンドのみ。blob で保存したドキュメントリストについて情 報を検索する際、blob バックエンドは blob の中身をインターバルごとに分 割して検索します。インターバルがこの値より小さい場合、すべての値をデー タベースから取得して、最終的な検索は Perl コードで行われます。

word_id_bits

With column or phase backends, DBIx::FullTextSearch maintains a numeric id for each word to optimize the space requirements. The word_id_bits parameter specifies the number of bits to reserve for this conversion and thus effectively limits number of distinct words that may be indexed. The default is 16 bits and possible values are 8, 16, 24 or 32 bits.

columnphase バックエンドでは、DBIx::FullTextSearch はスペー ス節約のために、各単語に数値の id を割り当ててメンテナンスしています。 word_id_bits パラメータはこの変換表で使うビット数を指定し、インデクス で許容される単語を効率的に制限することができます。デフォルトは16bit で、 とりうる値は 8, 16, 24, 32 ビットです。

word_id_table

Name of the table that holds conversion from words to their numeric id (for column and phrase backends). By default is the name of the index with _words suffix.

単語から数値idへの変換表を保持するテーブル名(columnphrase バッ クエンド向け)。デフォルトでは、インデクスの名前の後ろに _words をつけ たもの。

doc_id_bits

A number of bits to hold a numeric id of the document (that is either provided by the user (with default frontend) or generated by the module to accomplish the conversion from the string name of the document). This value limits the maximum number of documents to hold. The default is 16 bits and possible values are 8, 16 and 32 bits for blob backend and 8, 16, 24 and 32 bits for column and phrase backends.

ドキュメントの数値id (ユーザによって指定される(default バックエンド) か、モジュールによってドキュメントの文字列名から変換されて生成される) を保持するビット数。この値によって、保持するドキュメント数の最大値が制 限されます。デフォルトでは 16ビットで、とりうる値は blob バックエン ドでは 8, 16, 32 bit, columnphrase バックエンドでは 8, 16, 24, 32 bit です。

doc_id_table

Name of the table that holds conversion from string names of documents to their numeric id, by default the name of the index with _docid suffix.

ドキュメントの文字列名から数値 id への変換表を保持するテーブル名。デフォ ルトではインデクスの名前に _docid をつけたもの。

count_bits

Number of bits reserved for storing number of occurencies of each word in the document. The default is 8 and possible values are the same as with doc_id_bits.

ドキュメント内の各単語の出現数を保存するためのビット数。デフォルトは 8bit で、とりうる値は doc_id_bits と同じです。

position_bits

With phrase backend, DBIx::FullTextSearch stores positions of each word of the documents. This value specifies how much space should be reserved for this purpose. The default is 32 bits and possible values are 8, 16 or 32 bits. This value limits the maximum number of words of each document that can be stored.

phase バックエンドでは、DBIx::FullTextSearch は各単語のドキュメント 内の位置を保存します。この値は、この目的のために使用するスペースを指定 します。デフォルトは 32bit で、とりうる値は 8, 16, 32 ビットです。この 値によって、各ドキュメントが保持できる単語の最大数が制限されます。

index_splitter

DBIx::FullTextSearch allows the user to provide any Perl code that will be used to split the content of the document to words when indexing documents. The code will be evalled inside of the DBIx::FullTextSearch code. The default is

DBIx::FullTextSearch は、ドキュメントのインデクシングの際、ユーザの指 定した任意のPerl コードによってドキュメントの中身を単語に分割すること ができます。コードは DBIx::FullTextSearch のコード内で eval されます。 デフォルトは

        /(\w{2,$word_length})/g

and shows that the input is stored in the variable $data and the code may access any other variable available in the perl_and_index_data_* methods (see source), especially $word_length to get the maximum length of words and $backend to get the backend object.

で、入力は変数 $data に格納されていて、コードは他にも perl_and_index_data_* メソッド内で利用可能な変数、特に $word_length で単語の最大長、$backend でバックエンドオブジェクトにアクセスできる ことができます(詳しくはソースを見てください)。

The default value also shows that by default, the minimum length of words indexed is 2.

デフォルト値によると、インデクスされる単語の長さの最小値は 2 です。

search_splitter

This is similar to the index_splitter method, except that it is used in the contains_hashref method when searching for documents instead of when indexing documents. The default is

index_splitter メソッドに似ていますが、ドキュメントのインデクシング ではなく、contains_hasherf メソッドでドキュメントを検索する際に使わ れます。デフォルトは

       /([a-zA-Z_0-9]{2,$word_length}\*?)/g

Which, unlike the default index_splitter, allows for the wild card character (*).

で、デフォルトの index_splitter とちがって、ワイルドカード文字 (*) が使用可能です。

filter

The output words of splitter (and also any parameter of (e)contains* methods) are send to filter that may do further processing. Filter is again a Perl code, the default is

splitter によって出力された単語 (また (e)contains* メソッドのすべての パラメータ) は filter に送られ、処理されます。filter も任意の Perl コー ドで、デフォルトは

        map { lc $_ }

showing that the filter operates on input list and by default does conversion to lowercase (yielding case insensitive index).

で、入力のリストに対してデフォルトで lowercase 変換をかける (つまり大 文字小文字をインデクスで区別しない) ことがわかります。

init_env

Because user defined splitter or filter may depend on other things that it is reasonable to set before the actual procession of words, you can use yet another Perl hook to set things up. The default is

ユーザ定義の splitter や filter は、実際の単語処理の前に実行されるべき ものに依存していることが考えられるので、セットアップ用の Perl フックも 利用できます。デフォルトは

        use locale

です。

stoplist

This is the name of a DBIx::FullTextSearch::StopList object that is used for stop words.

ストップワードに使われる DBIx::FullTextSearch::StopList オブジェク トの名前です。

stemmer

If this option is set, then word stemming will be enabled in the indexing and searching.

このオプションをセットすると、インデクシングと検索において、単語のステ ミングが有効になります。

The value is the name of a Lingua::Stem recognized locale. Currently, 'en', 'en-us' and 'en-uk' are the only recognized locales. All locale identifiers are converted to lowercase.

値は Lingua::Stem が認識できる locale の名前です。locale はすべて小 文字に変換されます。

table_name

For table frontend; this is the name of the table that will be indexed.

table フロントエンド用; インデクスされるテーブル名です。

column_name

For table frontend; this is a reference to an array of columns in the table_name that contains the documents -- data to be indexed. It can also have a form table.column that will be used if the table_name option is not specified.

table フロントエンド用; ドキュメントを含む table_name 内のカラム の配列リファレンスで、インデクスされるデータとなります。table_name を省略した時には、table.column という書き方を使うこともできます。

column_id_name

For table frontend; this is the name of the field in table_name that holds names (ids) of the records. If not specified, a field that has primary key on it is used. If this field is numeric, it's values are directly used as identifiers, otherwise a conversion to numeric values is made.

table フロントエンド向け; table_name のレコードの名前 (id) を保 持しているフィールド名です。指定されない場合、primary key となっている フィールドになります。このフィールドが数値の場合、この値が直接 id とし て利用されますが、そうでない場合は数値への変換が行われます。


ERROR HANDLING

The create and open methods return the DBIx::FullTextSearch object on success, upon failure they return undef and set error message in $DBIx::FullTextSearch::errstr variable.

create と open メソッドは成功時に DBIx::FullTextSearch オブジェクトを 返し、失敗すると undef を返し、エラーメッセージを $DBIx::FullTextSearch::errstr にセットします。

All other methods return reasonable (documented above) value on success, failure is signalized by unreasonable (typically undef or null) return value; the error message may then be retrieved by $fts->errstr method call.

その他のメソッドは成功時には求められている値 (上記にドキュメントした通 り)を返し、失敗した際には何らかの (おそらく undef かヌル) の返り値でわ かります。エラーメッセージは $fts->errstr メソッドで取得できま す。


VERSION

This documentation describes DBIx::FullTextSearch module version 0.60.

このドキュメントは DBIx::FullTextSearch モジュール version 0.60 につい て記述しています。


BUGS

Error handling needs more polishing.

エラー処理はもうすこしきれいにする必要がある。

We do not check if the stored values are larger that specified by the *_bits parameters.

格納された値が *_bits パラメータで指定された値より大きいかどうかはチェッ クしていません。

No CGI administration tool at the moment.

現状、CGIのアドミニストレーションツールはありません。

No scoring algorithm implemented.

スコアリングのアルゴリズムは実装していません。


DEVELOPMENT

These modules are under active development. If you would like to contribute, please e-mail tj@anidea.com

このモジュールは活発に開発が行われています。コントリビュートしたければ、 tj@anidea.com までメールしてください。

There are two mailing lists for this module, one for users, and another for developers. To subscribe, visit http://sourceforge.net/mail/?group_id=8645

モジュールのユーザとデベロッパ向けに、2つメーリングリストがあります。 subscribe するには、 http://sourceforge.net/mail/?group_id=8645 を見て ください。


AUTHOR

(Original) Jan Pazdziora, adelton@fi.muni.cz, http://www.fi.muni.cz/~adelton/ at Faculty of Informatics, Masaryk University in Brno, Czech Republic

(Current Maintainer) T.J. Mather, tjmather@tjmather.com, http://www.tjmather.com/ New York, NY, USA


CREDITS

Fixes, Bug Reports, Docs have been generously provided by:

バグフィクス、レポート、ドキュメントは提供して頂いた方々:

  Ade Olonoh
  Kate Pugh
  Sven Paulus
  Andrew Turner
  Tom Bille
  Tarik Alkasab
  Joern Reder
  Dan Collis Puro
  Tony Bowden
  Stephen Patterson

Of course, big thanks to Jan Pazdziora, the original author of this module. Especially for providing a clean, modular code base!

もちろん、このモジュールの原作者である Jan Pazdziora に大いに感謝しま す。特に、きれいなモジュールコードべースをつくってくれたことに!


COPYRIGHT

All rights reserved. This package is free software; you can redistribute it and/or modify it under the same terms as Perl itself.


SEE ALSO

DBIx::FullTextSearch::StopWord, Class::DBI::mysql::FullTextSearch


OTHER PRODUCTS and why I've written this module

(If you use Java, then I would highly recommend looking into Lucene. For more information, see http://www.lucene.com )

(Java をお使いなら、Lucene を見てみることを強くお勧めします。詳細は http://www.lucene.com を見てください)

I'm aware of DBIx::TextIndex and DBIx::KwIndex modules and about UdmSearch utility, and about htdig and glimpse on the non-database side of the world.

DBIx::TextIndexDBIx::KwIndex といったモジュールの存在や、 UdmSearch などのユーティリティ、さらには htdig や glimse のようにデー タベースに関係ないものがあるのも知っています。

To me, using a database gives reasonable maintenance benefits. With products that use their own files to store the information (even if the storage algorithms are efficient and well thought of), you always struggle with permissions on files and directories for various users, with files that somebody accidently deleted or mungled, and making the index available remotely is not trivial.

私にとっては、データベースを使うことでメンテナンス面での十分な利益があ ります。情報を独自のファイルに格納するような製品 (ストレージアルゴリズ ムが効率的でよく考えられていたとしても) の場合、多くのユーザのためのファ イルやディレクトリのパーミッションの問題や、誰かが間違ってファイルを消 したり壊してしまったりすることといつも格闘することになり、またインデク スをリモートで利用可能にすることは簡単ではありません。

That's why I've wanted a module that will use a database as a storage backend. With MySQL, you get remote access and access control for free, and on many web servers MySQL is part of the standard equipment. So using it for text indexes seemed natural.

こうした理由で、ストレージのバックエンドにデータベースを使いたかったの です。MySQL を使うと、リモートアクセスもアクセス制御も自由に行えますし、 多くのウェブサーバでは MySQL は標準装備されています。よってテキストの インデクスとして MySQL を使うのは自然でしょう。

However, existing DBIx::TextIndex and UdmSearch are too narrow-aimed to me. The first only supports indexing of data that is stored in the database, but you may not always want or need to store the documents in the database as well. The UdmSearch on the other hand is only for web documents, making it unsuitable for indexing mailing-list archives or local data.

しかし、既存の DBIx::TextIndex や UdmSearch は私にとっては対象範囲 が狭すぎます。前者はデータベースに格納されたデータのインデクスしかサポー トしていませんが、ドキュメントいつもデータベースに入れるとは限らないで しょう。一方 UdmSearch はWeb文書に特化しているので、メーリングリストの アーカイブやローカルデータのインデクスには向いていません。

I believe that DBIx::FullTextSearch is reasonably flexible and still very efficient. It doesn't enforce its own idea of what is good for you -- the number of options is big and you can always extend the module with your own backend of frontend if you feel that those provided are not sufficient. Or you can extend existing by adding one or two parameters that will add new features. Of course, patches are always welcome. DBIx::FullTextSearch is a tool that can be deployed in many projects. It's not a complete environment since different people have different needs. On the other hand, the methods that it provides make it easy to build a complete solution on top of this in very short course of time.

DBIx::FullTextSearch は十分フレキシブルでまた十分高速だと思っています。 なにが最適かを押しつけたりはしません -- 選択肢の数は大きく、提供済みの もので満足できなければ、いつでも独自のフロントエンドやバックエンドでモ ジュールを拡張することができます。また、既存のものの拡張も、1つ2つのパ ラメータの追加で新たに機能を追加することができます。もちろん、パッチは いつでも歓迎です。 DBIx::FullTextSearch は多くのプロジェクトで利用可能 なツールです。多くの人にはそれぞれのニーズがありますから、このモジュー ルは完全な環境ではありません。一方、このモジュールが提供しているメソッ ドを元にして、完全なソリューションを単期間で構築するのは容易でしょう。