The API has matured with the 2.x branch. Time to get out of the black box this module has been living in and document the thing.

CommentFileSizeAuthor
#2 luceneapi-documentation-r40.pdf121.43 KBcpliakas

Comments

cpliakas’s picture

cpliakas commented

Massive documentation effort underway. First drafts of the following sections have been written:

  • Introduction
    • The Problem with Drupal Search
    • Why Search Lucene API?
    • Maintainer
  • Module Version
    • Stable Releases
    • Development Releases
  • Installation
cpliakas’s picture

cpliakas commented
StatusFileSize
new luceneapi-documentation-r40.pdf121.43 KB

PDF snapshot of documentation.

shunting’s picture

shunting commented

Will one cron run be enough to create the entire new lucene index? If not, you might wish to add verbiage like: "Administrators for large sites, especially those who have "hijacked" Drupal's existing Search form*, may wish to increase the frequency of their cron jobs until the site is completely re-indexed."

* And who wouldn't want to do that?

cpliakas’s picture

cpliakas commented

Great recommendation. Although this may seem intuitive to some, the documentation is geared towards people who may not have as deep of an understanding as more experienced users. I will most definitely add this.

shunting’s picture

shunting commented

I don't get why the luceneapi_node_luceneapi_facet function constructs its return values the way that it does. Quoting the function in relevant part:

...
if (module_exists('date_api')) {
$return[5] = 'Changed after';
$return[10] = 'Created after';
}
if (module_exists('taxonomy')) {
$return[20] = 'Taxonomy';
}
...
}
$form[0]['textfields']['author'] = array( ....

$form[5]['textfields']['changed'] = array( ....

$form[10]['textfields']['created'] = array( ...

$form[15]['type'] = array( ...

$form[20]['category'] = array(

What's with the numeric keys incremented by five? If the numbers aren't meaningful, why not just push values onto the returned array? And if they are meaningful, could they be CONSTANTs? And if something clever is being done with them, maybe it's too clever?

cpliakas’s picture

cpliakas commented

Please see comment in #502498 regarding this issue.

cpliakas’s picture

cpliakas commented

Added documentation to the handbook on drupal.org. All future documentation will be added there.

B Musical’s picture

B Musical commented

Hi cpliakas,
Thanks for authoring lucene api module... A few example on how to add field and on how to insert algorithm to configure doc scores (API 2 version) would be really helpful for novice like me to digest.. I tried the following hook implementation checking one of your reply..

function lucenermgfacete_luceneapi_document_alter($doc, $node, $module, $type) {
  // bail if we are not dealing with nodes
  if ('node' != $type) {
    return;
  }

  // add the field to the document as a keyword.  Feel free to use another field type.
  luceneapi_field_add($doc, 'keyword', 'id', $node->field_empno[0]['value']);
  luceneapi_field_add($doc, 'keyword', 'exp', $node->field_experience[0]['value']);
  luceneapi_field_add($doc, 'keyword', 'skill', $node->field_skillset[0]['value']);
  luceneapi_field_add($doc, 'keyword', 'prevproj', $node->field_previousprojects[0]['value']);

}

Other than the 'id' remaining fields aren't retrieving any results... for example "id:123456" works but "prevproj:insurance" ain't..
i'm quite new to drupal.. Sorry if i had posted this in the wrong place....

cpliakas’s picture

cpliakas commented

Hi B Musical.

For all fields other than "id", change the second parameter from "keyword" to "unstored". Visit the Understanding field types section of the Zend Framework documentation to get more details on what these values mean.

Thanks for the examples!
~Chris

B Musical’s picture

B Musical commented

Thanks a Ton for the quick response.. My issue was resolved... I'm just starting to realize the potential of lucene and once again i like to thank you for authoring this API.. once my knowledge is upgraded I take a oath that i will repay your help by contributing the best of mine to this module...

Regards,
bharani

Anonymous’s picture

Anonymous (not verified) commented

Subscribe

Anonymous’s picture

Anonymous (not verified) commented

Hello Chris,

I'm happy with the faceted indexing on that this module provides but I am struggling to implement a search similar to what is described in this thread for the 1.0 api: http://drupal.org/node/408128#comment-1392556

I am trying to add a checkbox that will limit the search to a certain facet.

In trying to implement the following code I have updated the function calls:

/**
* Adds query to filter by location.
*/
function mymodule_facet_handler() {
  // gets facet value passed by user
  $location = luceneapi_facet_value_get('location', '');   // added "get"

  // returns subquery to filter by location, in this case it is a wildcard query
  // NOTE: see luceneapi.query.inc for available query types and parameter definitions
  return luceneapi_query_get('wildcard', $location, 'location');   // syntax change?
}

The luceneapi_query_get call is confusing me. It seems under the 2.0 api it only has one parameter, the node type.

Following the comment posted above I have also considered going the other route, implementing hook_luceneapi_query_alter(), but again I get stuck at the luceneapi_query_get() call.

From what I can tell, a new function called luceneapi_query_parse() seems to take over where the old get() query left off. Am I going in the right direction here? All I'm trying to do is limit the search to the "title" field, and/or a faceted field.

Anonymous’s picture

Anonymous (not verified) commented

At some point it would be great if luceneapi_subquery_add() was documented. I would also be interested in knowing more about how the $module variable that is used throughout the api.

As for my project to limit the search to one field only - I really want to put it on hold until there is some documentation available... or perhaps revert back to the 1.6 branch. Sigh.

cpliakas’s picture

cpliakas commented

Hi Ryan.

The 2.0 API is substantially different from the 1.0 API, and defining facets in a 1.0 manner will not work. $module is the module executing the search, which will be 'luceneapi_node' for Search Lucene Content. $type is the type of content that is being indexed. Search Lucene Content index nodes, so $type will be 'node' in most cases.

In terms of limiting the search to one field, you can do this via the "Content bias" tab. Just change all of the fields you don't want to search by default to "Don't search". If the fields you want to search is not exposed as a bias field already, simply add one via hook_luceneapi_node_bias_fields() similar to the following:

/**
 * Implementation of hook_luceneapi_node_bias_fields().
 */
function mymodule_luceneapi_node_bias_fields() {
  $fields = array();

  // The array key is the name of the Lucene field that will be exposed as a
  // bias field.  Check the "Index statistics" tab for a list of the Lucene
  // fields in the index.
  $fields['myfield'] = array(

    // The title is the display name of the field in the "Content bias" tab.
    'title' => t('Body text'),

    // The default boost factor.  A higher number places more importance on the
    // field during searches.  Setting this value to 0 will place no importance
    // meaning that it won't be searched when a search is executed through the
    // Search Lucene Content search form.
    'default' => '1.0',

    // A description of the field displayed in the "Content bias" tab.
    'description' => t('The full rendered content of the page.'),
  );

  return $fields;
}

Again, the 1.0 API posts do not apply to the 2.0 API. The change from 2.0 to 3.0 is expected to be far less drastic, and hopefully the API will more or less be tweaked.

Hope this helps,
Chris

cpliakas’s picture

cpliakas commented
Status: Active » Closed (fixed)