Organic group Apachesolr integration

I'm not real familiar with apachesolr implementation. a few thoughts:

- facets should work even if og_access is disabled. note that there will be no need to for node access control in this case.
- module_exists() instead of module_list()
- node admins probably should still see facets based n their subscribed groups, even though they can see everything.

Right - this does sound like it should be separate from the node access module - node access will be handled independently there.

Should this jsut be a separate module?

I think the other issue was closed for just the node access aspects of the proposal. i.e. we should not need a distinct implementation per node access module.

To the extent that OG needs facets that are distinct from other types of nodes, this could be a separate module.

Also, feedback appreciated on the notion of trying to make a centralized hook for managing facets/blocks: http://drupal.org/node/339467

Hi Aufumy,

It really wouldn't be hard to convert this to using its own field. If you want help with it, ping me and I'll try to assist. I don't think we will want to commit it piggy backing on nodeaccess, but everyone really wants this feature!

Best,
Jacob

@Jacob - I assume this could just add one or more dynamic fields like CCK fields using hook_apachesolr_update_index().

Something like (I;m not sure this this the exact format of the group info on the loaded node):

function apachesolr_og_apachesolr_update_index(&$document, $node) {
  if (!($node->og_groups)) {
    return;
  }

  $group_info = array(
     'index_type' => 'integer',
     'multiple' => TRUE,
     'name' => 'og_gid',        
  );
  $index_key = apachesolr_index_key($group_info);
  foreach ($node->og_groups as $gid) {
    $document->setMultiValue($index_key, $gid);
  }
}

Is there any way to insure that there is not collision between dynamic fields? Maybe we should be adding the string 'cck' or some such to the cck fields? I gues the have 'field_' as a somewhat distinct prefix now.

why do we need to modify the schma if we have existing dynamic fields?

Actually - seems we don't have a dynamic field that is integer (rather than a sint).

We need to alter the code so that we keep namespaces more separate. Also, for schema I think so we should think about having the int fields by integer not sint by default.

see: http://drupal.org/node/340222#comment-1129870

HI Audry,

This looks really good. I have a few ideas though you may want to consider:

#Shouldn't this use the same apachesolr_index_key function?
$blocks['imfield_og_gid'] = array('info' => t('ApacheSolr Search: Filter by group'));

#Is this inefficient:

while ($row = db_fetch_object($result)) {
$all_groups[$row->nid] = $row->og_description;
}

#I don't know how much this matters. I suppose only on a site like g.d.o. would this be an issue. I don't think we need to worry about it now, and since we are planning to use this code to index g.d.o., I guess we'll find out! The only alternative is to iterate results twice I suppose and extract the gids for an IN() query, but those are also pretty slow... Or do many selects() (this might actually be faster).

I think if we fix the first thing so that the naming stays consistent even if we change the function to generate the name, this is good to go.

Best,
Jacob

@aufumy - seems to be some code-style issues. Also, the planned shift to return minimum data will require some alteration here to add fl params to the query.

see: http://drupal.org/node/338534

"we could use a default fl parameter something like fl=id,title,comment_count,type,changed,score,url,uid,name and get a Solr-generated snippet of the body back in the highlighting."

Basically, any module that needed additional fields would need to alter the query to add additional fields. Probably you can just move forward with this, but we'll need to revisit once that other issue gets some code/traction.

Hi Audry,

I don't have an o.g. site to test this on, but I'll get the g.d.o. DB from peter and give it a shot this week. It looks great though so I assume we'll commit it by Friday.

Thanks for making this!

Best,
Jacob

Obviously the commit did not happen yet - needs to be re-rolled for APi changes to facet handling.

Here is a partial re-roll.

Info file still needs a change or two, etc..
Major bug is the facet block, doesn't include the search query. Not sure why yet.

Hey guys. groups.drupal.org is getting close to a d6 launch. Any chance someone can push this toward commit?

A quick question about this - do you see there being a reasonable use case for multi-site faceting on groups? Possibly we should just exclude that possibility for now and focus on making it work since site.

Also, for other facets (like taxonomy terms) we are not adding links to the search results - why is that important for groups?

Nah, multi-sites are not likely to share groups. Thats just too mind bending. Groups are really for webmasters that like one site instead of many. I think you can ignore multi-site here.

Perhaps someone else can respond top the links question.

I've got this mostly working - but things break due to the ordering of the call to hook_nodeapi (which we should likely remove anyhow) and hook_apachesolr_process_results

better - correctly indexes gid as 0 for no groups.

doh - also missing a very obvious little thing - a "search within this group" block.

committing this patch (no search block) - open another issue for follow-ups. Moshe says something above about restricting the facet block based on the current user's groups - not sure I understand the intent of that.

Note there is a switch from calling hook_nodeapi to a new _alter hook.

Since OG itself does not (currently) add links to the groups for core search results - this seemed possibly like a theme-level decision.

FYI, this is running on groups.drupal.org now.