I have a custom "tuple" field which needs to be indexed. It maps to a solr.PointType field. Is there any documentation how I would integrate this in search_api? (And afterwards in search_api_solr?)

Comments

Project:Search API» Entity API
Component:Plugins» Documentation

Finding fields and their data is done by the Entity API – I don't really know what has to be done there for custom fields, best ask fago. *Moving to his issue queue*

Solr will then automatically index the data. However, if you need to index it with a certain type, this is considerably more complicated. If this is custom work, which won't be published, I'd suggest just already returning the tuple data for the Entity API in the way Solr excpects it, and then using a custom field override (define the Solr field used for the tuple explicitly, using your desired type) in schema.xml.
Otherwise, you'd have to somehow work around the fact that Solr will probably index the two parts of the tuple separately. I don't really know how you might do this cleanly, there isn't really support for such a data type in the Search API (and in the Entity API).

I do need to index it with a certain type. With the apachesolr module it was quite easy to have my data indexed. There were hooks to expose my custom field to solr and have it end up in the solr field I wanted.

What I had before I noticed I would need to use search_api (since some apachesolr module won't be upgraded but will migrate to search_api):

In schema.xml:

    <fieldType name="point" class="solr.PointType" dimension="3" subFieldType="long" />
</types>
<fields>
    <field name="qualification" type="point" indexed="true" stored="true" multiValued="true" />

And in an indexing callback I returned the correct solr field name and values. I'm not sure if your explanation means this is possible with search_api.

Status:Active» Fixed

Just implement hook_entity_property_info() to add your data. See http://drupal.org/node/1021466
Perhaps we should add a note to this somewhere in the search_api docs?

And in an indexing callback I returned the correct solr field name and values. I'm not sure if your explanation means this is possible with search_api.

Sadly it's not that easy. Since the Search API isn't Solr-specific, there is no mechanism for adding custom Solr types, only the defined types can be used. This is also a restriction in the Search API — if you have more complex data, you can use the "structure" type, but that will split into fields with primitive types again, and these will be indexed separately by the Search API.
As said, you could (either directly in the property info, or via a data alteration, or via the hook_search_api_index_items_alter()) merge the (apparently) three values into a single one, in the format that Solr expects. Then you could lookup (via Solr's admin interface, or the log file) which field the Search API Solr search module uses for your field, and add a custom override (like yours above, only with the respective field name instead of "qualification").

I'm open, though, to add a custom hook just for the Solr module for altering the way data is indexed. Then this might be easier. Would you create another issue for that, in the search_api_solr issue queue?

Perhaps we should add a note to this somewhere in the search_api docs?

You are right, this is frequently asked. I now put it into the README.txt.

Just implement hook_entity_property_info()

I've followed the link and the explanation is confusing me. Even in entity.api.php, which is referred in the documentation, there isn't an explanation about what property_callbacks should do.

I was unsuccessful at even getting my custom field to display in the list of available fields to index when property_type is not one of the default ones.

I've looked at how search_api_attachments adds its options to the field overview but the hook it uses (hook_search_api_alter_callback_info) is completely undocumented.

Man, this isn't easy or even somewhat fun.

I'm open, though, to add a custom hook just for the Solr module for altering the way data is indexed.

Shouldn't the API support this by default? I can imagine that the location field wants to expose lat/lon or a geohash field that can be indexed by different backends differently. Solr has a LatLonType and MySQL also supports some kind of location field.

I've looked at how search_api_attachments adds its options to the field overview but the hook it uses (hook_search_api_alter_callback_info) is completely undocumented.

It is documented. In the standard documentation file. Odd place for it, I know.

As for property callbacks I'd advise you to look at some of the examples for core fields and entities in the Entity API.

Shouldn't the API support this by default? I can imagine that the location field wants to expose lat/lon or a geohash field that can be indexed by different backends differently. Solr has a LatLonType and MySQL also supports some kind of location field.

It not only shouldn't, but simply can't. How should a module wanting to implement its own backend know what custom types are out there in contrib modules, or will be there at some point in the future? Standardising the available types is the only practical way there, and sadly a downside of this is that certain things will be harder to implement.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.