ZCatalog

Begriffserkl�rung und Funktionsweise

uebersetzt von http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html#c37ac15c11c14

Siehe auch:

https://dzug.org/Members/smt/ZopeBuch/SearchingZCatalog.html/view - ausf�hrliche Erl�uterung

Der ZCatalog ist Zope's Such- und Indexfunktion. Ein Katalog besteht aus einer Menge benannter Indizes, einer Menge katalogisierter Objekte und aus einem Datensatz (record) MetaDaten? f�r jedes Objekt. Ein Katalog wird f�r Indexsuchen auf den katalogisierten Objekten genutzt.

Wenn ZCatalog ein Objekt indiziert indentifiziert es die Index-Eintr�ge f�r jedes seiner Indizes. Im ersten Schritt interpretiert er den IndexBezeichner? als Attribut oder parameterfreie Methode des Objekts[13]?. Er holt sich den Wert oder ruft die Methode auf, um den den Wert des Objekts f�r den jeweiligen Index zu erhalten. Der Wert wird abh�ngig vom IndexTyp? in eine Reihe von IndexAusdruecke?-n transformiert, unter welchen das Objekt dann indiziert wird (den Satz verbessern?). Eine gew�hnliche Suche besteht immer aus der Abfrage aller Objekte die unter einem bestimmten IndexAusdruck? indiziert sind. Derzeit unterst�tzen die IndexTyp?-en verschiedene Typen von komplexen QUeries?. Dies wird sich hoffentlich in Zukunft �ndern. (noch aktuell?)

ZCatalog unterst�tzt drei IndexTypen?: [text]?, [field]? und [keyword]?. Ein TextIndex? splittet den Wert in einzelne W�rter auf und nimmt jedes Wort als IndexAusdruck?, ein FieldIndex? nimmt den Wert selber als IndexAusdruck?. Bei einem KeywordIndex? mu� der Wert selber eine Folge von Elementen sein, er nimmt jedes Element als IndexAusdruck?.

Eine ZCatalog-Abfrage ist eine Abbildung, die den IndexBezeichner?-n (und manchmal auch von den IndexBezeichnern? abgeleiteten Bezeichnern) QUery? Spezifikationen zuordnet. (geht das vielleicht auch einfacher! ;-) Das Ergebnis ist eine Schnittmenge aller Objekte die bei der Abfrage der besagten Indizes f�r die entsprechende QuerySpezifikation? erhalten wurden. Wenn die Abbildung leer ist (oder keinen der Indizes benennt (?) ), so besteht das Ergebnis aus allen katalogisierten Objekten.

KeywordIndizes? sind FieldIndizes? mit einem leicht verschiedenen Indizierungsablauf. Ihre Suchm�glichkeiten sind identisch mit denen der FieldIndizes?. Ein FieldIndex? unterst�tzt or(oder) und range(Bereich) -Suchen. Eine 'or'-Suche findet alle Objekte, die unter irgendeinem der angegebenen Werte indiziert sind. Die AbfrageSpezifikation? ist entweder ein einzelner Wert (die Abfrage ist so nur noch eine elementare Abfrage) oder einer Folge von Werten nach denen gesucht werden soll. Eine 'range'-Suche findet alle Objekte die unter einem BereichsAusdruck?-s indiziert sind. F�r eine BereichsAbfrage? mu� die AbfrageAbbildung? den Bezeichner [index_usage]? auf eine BereichsSpezifikation? abbilden. Eine BereichsSpezifiaktion? beginnt mit einem Bereich(range), gefolgt von min, max oder min:max. Die AbfrageSpezifikation? ist wiederum entweder ein einzelner Wert oder eine Folge von Werten. Wenn die BereichsSpezifikation? ein min enth�lt, so begrenzt der Minimalwert den Bereich von unten, wenn sie ein max enth�lt, so begrenzt der Maximalwert den Bereich von oben.

Die AbfrageSpezifikation? eines TextIndex? ist entweder ein einzelner AbfrageString? oder eine Folge von AbfrageString?-s. Wenn es eine Folge ist, so ist das Ergebnis die Schnittmenge der Ergebnisse von den einzelnen AbfrageString?-s[14]?. Der AbfrageString? wird als ein aus AbfrageBegriff?-en (optional mit AbfrageOperator?-en and, or, andnot, ...(�nhlich) bzw. mit Klammern gruppiert) bestehender AbfrageAusdruck? interpretiert. Ein AbfrageBegriff? ist f�r gew�hnlich ein Wort oder ein Satz(phrase). Ein Satz ist eine in " eingeschlossene Folge von W�rtern. S�tze werden in �hnlichkeits-Suchen der enthaltenen W�rter transformiert. Der Katalog delegiert alle Operationen an W�rtern an das VOcabulary? (auch LExicon? genannt). Wenn das VOcabulary? des Katalogs WildCard?-s(Jokerzeichen) unterst�tzt, so kann auch der AbfrageBegriff? WildCard?-s enthalten. In diesem Falle werden diese in mit or verbundene Wortfolgen (ohne WildCards?) erweitert. Wenn ein optionaler Operator weggelassen wurde, so wird der 'or'-Operator automatisch eingesetzt. Diese Abfrage wird schlie�lich unter Beachtung der Gruppierung von links nach rechts ausgef�hrt, wobei die Operatoren auf nat�rliche Art interpretiert werden. - Schwierig? Hier folgen nun einige Beispiele:

Beispiel 3.2. TextIndex? AbfrageAusdrucks?

tree searches for objects indexed under tree
tree bush searches for objects indexed under tree or bush
tree and bush - searches for objects indexed under both tree and bush
tree and not bush - searches for objects indexed under tree but not bush "holy tree"
this is a phrase. - It searches for objects indexed under holy and tree with some occurrences of these words near together.
grass and (tree or bush) - searches for objects indexed under grass, that are also indexed under tree or bush
tree'' - searches for objects indexed under any term starting with tree. We assume here, that the catalog uses Zope's globbing vocabulary. This vocabulary supports the wildcards ' and ?'. They match any character sequence or any character, respectively.

The catalog maintains for each cataloged object a collection of meta data, data about the object. It consists of data_recordid and the attributes or parameterless methods defined via the Meta Data Table tab. These attributes/methods are evaluated during catalog time, similar to the determination of an object's value for indexing, and stored inside the catalog independent from the object. Zope's search interface wizard uses these meta data to construct the report columns. I view this feature very critical as the so called meta data are actually not additional meta data but can be directly obtained from the object. Storing it with the catalog increases memory consumption and cataloging time; it introduces redundancy, which usually is not a good idea. I define a field only, if either of the following conditions is met: it is very small, such as id, it helps me to detect inconsistencies between the catalog and the object. This is true for bobobase_modification_time, the time, the object was last changed in ZODB., it is a computation intensive method, such as e.g. an intelligent summarization.

The catalog associates internally a unique number with each object, data_recordid. It is part of the object's meta data table and available for each retrieved object. During cataloging, the catalog also stores the path to the object in order to find it again later during retrieval. The catalog provides two methods, that return either the path or the object itself, given a data record id: getpath and getobject. From Zope 2.3 on, the result of a catalog search behaves like a sequence of brain objects. Each such object describes one hit. Its attributes are the meta data values associated with the object. Furthermore, it provides methods getPath and getObject to access the corresponding path and object, respectively. With these new methods, you will probably no longer use the unique numbers.

Cataloging is only loosely coupled to the fate of an object. If the object is changed after it was cataloged, the cataloged information may no longer be accurate, if the object is deleted, the cataloged information about the object is still there. To fix such discrepancies, the catalog must be resynchronized. This can be done either globally, through the method manage_catalogReindex or for a single object with catalog_object or uncatalog_object (for deletion). There is a mixin class, CatalogAware?, that helps (a bit) with the synchronization. CatalogAware? objects handle creation and deletion automatically and provide a method index_object to be called explicitly after an object is modified. index_object is easier to call then the catalog's catalog_object. Of course, the object must find the catalog to be updated. It uses a catalog name, which initially is Catalog but can be changed.

How get objects cataloged? When they are CatalogAware?, they will catalog themselves automatically when they come into existence. They can be cataloged explicitly with the ZCatalog method catalog_object. Alternatively, the catalog provides the method manage_catalogFoundItems for mass cataloging. Starting from the container containing the catalog, it searches all objects that meet given search criteria and catalogs them. If necessary, single objects can later be removed manually. These functions are available from Zope's management interface, too.

ZCatalog is an essential but unfortunately rather shaky Zope component. If something behaves strangely, then you have hit a catalog bug with some probability.

ZCatalog inherits from Folder. This implies, it is an ObjectManager?. Usually, you will place DTML methods into the catalog that present search results. This implies that they have direct access to the catalog's methods. You may also place the objects to be cataloged there. In this case, they can directly use the catalogs methods for cataloging control.

ZCatalog's constructor is manage_addZCatalog.

ZCatalog's text indexes make use of Vocabularys. A vocabulary is a word expert. It knows how to split text into a sequence of words and then maps known words onto integers. A text index does not index the object under a word but really under an integer provided by a vocabulary for the word. The current Zope knows two types of vocabularies. A standard one and a globbing one. A globbing vocabulary recognizes the wildcards * and ? that match any word fragment or any single character, respectively. The globbing vocabulary expands such search terms into the sequence of words matching the term it knows about. The standard vocabulary does not recognize wildcards.