Author: dr
Date: Fri Feb 15 11:15:25 2008
New Revision: 7379
Log:
- Rough draft of design.
Modified:
experimental/Search/design/design.txt
Modified: experimental/Search/design/design.txt
==============================================================================
--- experimental/Search/design/design.txt [iso-8859-1] (original)
+++ experimental/Search/design/design.txt [iso-8859-1] Fri Feb 15 11:15:25 2008
@@ -10,17 +10,101 @@
Design description
==================
-
-Guidelines
-==========
+The search component provides an interface to allow for multiple search
+backends. For this to work, abstraction on several levels is required. First of
+all, the definition of documentation fields; and secondly the search query
+syntax. The logic is very similar to that of PersistentObject, where a mapping
+is made between class properties and database fields. For search a mapping is
+needed between class properties and search index fields. Finding persistent
+objects is done through the Database's component SQL abstraction to allow for
+multiple SQL dialects. The Search component requires something as well to allow
+for different search query dialects, similarly to what the Database component
+provides. Therefore the use of the search component will mostly be modeled
+after the design of the Database and PersistentObject components.
Classes
=======
+ezcSearchSession
+----------------
+
+ezcSearchSession is the main runtime interface for indexing and searching
+documents. Documents can be indexed calling index(), and searching for
+documents is done through find(). Unlike with the Persistent Object component,
+find does not simply return an array of objects for each of the found
+documents. Instead it returns an ezcSearchResult object containing information
+about the search result. The find() method accepts as parameter an object of
+class ezcSearchFindQuery (or one of it's children). This query object is
created by
+calling the createFindQuery() method on this class. Besides createFindQuery(),
+a method to create a query for deleting indexed documents will be provided too.
+
+
+ezcSearchSessionInstance
+------------------------
+
+Holds search session instances for global access throughout an application.
+
+ezcSearchDefinitionManager
+--------------------------
+
+Loads definition files that describe document types with all their fields. It
+depends on the backend on how those definitions are mapped to search engine
+specific fields/options.
+
+ezcSearchDocumentDefinition
+---------------------------
+
+Describes all the fields of one document type. It is loaded by the
+ezcSearchDefinitionManager and used by the backends to both index and find
+documents from the search backends. For each document field it stores a
+ezcSearchObjectProperty. It also defines a field with which a document
+can be uniquely identified. In future versions it could also group fields for
+easier searching of multiple fields etc.
+
+ezcSearchDocument
+-----------------
+
+And object that can be indexed with the search index. It is also returned as
+part of the ezcSearchResult.
+
+ezcSearchHandler
+----------------
+
+The base class that all search backends implement. The handlers now how to
+communicate to the backends, generate correct search query strings, and how to
+present results. Handlers can also accept search-backend specific options.
+
+ezcSearchSolrHandler
+--------------------
+
+An implementation of ezcSearchHandler that communicates with Apache
+Lucene/Solr. This will be the reference implementation.
+
+
+ezcSearchQuery
+--------------
+
+Implements a fluent language to query the search index. The methods are all
+quite the same as ezcDbQuery. It is inherited by ezcSearchFindQuery and
+ezcSearchDeleteQuery for respectably searching in, or deleting from the search
+index.
+
Data structures
===============
+
+ezcSearchObjectProperty
+ Defines the name of the document field, its type and a hint for the field
+ name in the search index.
+
+ezcSearchResult
+ Provides meta data about the search (time, number of results, etc.) as well
+ as an array of the found results. Depending on the database backend, the
+ array of found documents can be of different classes, but they all inherit
+ the ezcSearchDocument class.
+
+
..
--
svn-components mailing list
svn-components@lists.ez.no
http://lists.ez.no/mailman/listinfo/svn-components
