[commits] [Wiki] changed: Project/ContentBackend

[Chuck Hagenbuch]

chuck  Sun, 27 Nov 2011 23:20:01 +0000

Modified page: http://wiki.horde.org/Project/ContentBackend
New Revision:  12
Change log:  update for elasticsearch

@@ -28,28 +28,9 @@
  If possible performance-wise, a Horde-wide content tagging  
implementation, using content_master_ids, would allow relating tagged  
content between multiple Horde applications or content types.

  +++ Search

-Once we have Horde_Content, we should be able to build  
Horde_Content_Index on top of it that builds a full text index of  
anything in the horde_content_master table (using the content type  
objects to fetch each piece of content for indexing), with either  
mysql full-text as a backend (alternately  
http://www.sphinxsearch.com/), or something like Solr  
(http://lucene.apache.org/solr/). One challenge is handling  
permissions. Possibly we could store an object's permissions in the  
search backend itself, and update them along with any other changes to  
the object.
-
-++++ Potential search backends/resources
-
-Solr:
-* http://lucene.apache.org/solr/
-* http://lucene.apache.org/solr/tutorial.html#Getting+Started
-* https://issues.apache.org/jira/browse/SOLR-341
-* http://www.ibm.com/developerworks/library/os-php-apachesolr/index.html
-
-Sphinx:
-* http://www.sphinxsearch.com/
-*  
http://daylessday.org/archives/26-PECLsphinx-fast-fulltext-search-made-easy.html
-* http://capttofu.livejournal.com/13037.html
-
-Other:
-* http://www.luciddb.org/
-* http://hypertable.org/
-* http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html
-
+Horde_Content_Index will provide an interface for indexing  
Horde_Content objects in an !ElasticSearch  
(http://www.elasticsearch.org/) cluster. For now, each user will have  
their own index of all available content to avoid permissions issues.  
We may introduce a separate public index to avoid duplicating all  
public content, but right now there isn't an application for this.

  +++ Relationship service

  Store relationships between two master_ids, with an optional (?)  
relationship type. If we have a name or summary either in the master  
table or cached, we can quickly generate a summary of an items related  
objects.