Problem/Motivation

Reduce the amount of code that unnecessarily relies on Drupal structure (for example, the field listing). If we want to figure out what fields we want to show, we should have the flexibility to also show fields to come from the search server directly. In the case of Solr we need to be able to discover what fields we have available and show them without relying on Drupal.

Proposed resolution

Unidentified

Remaining tasks

Unidentified

User interface changes

Unidentified, probably a couple

API changes

Unidentified

Comments

drunken monkey’s picture

As said in #2138837: Add more flexibility in how we show data in an index, I don't think that's really a problem even now. We require metadata from the datasource on the fields, and for that we use Entity API metadata wrappers, but the metadata for those can come from anywhere – also from a Solr server.
For D8, this would very probably use TypedDataInterface and the Typed Data API instead, but the principle will be the same.

That being said, if we identify any other places that unnecessarily rely on Drupal structure, we should of course remove them. Eventually we should make sure that using a data source with external data works just as smoothly as those for entity data.

rooby’s picture

As said in #2138837: Add more flexibility in how we show data in an index , I don't think that's really a problem even now. We require metadata from the datasource on the fields, and for that we use Entity API metadata wrappers, but the metadata for those can come from anywhere – also from a Solr server.

Doesn't using entity api metadata wrappers indicate that a drupal entity is involved?

I'm currently doing a site with the apachesolr module where there is an external search index that is completely unrelated to drupal, no linked entities or anything like that.
Is that supported by current search api?

drunken monkey’s picture

Doesn't using entity api metadata wrappers indicate that a drupal entity is involved?

No, it doesn't. Metadata wrappers can be used to wrap any kind of data, they are just used to add metadata to the item. Creating a wrapper for entities is supported better, since it can automatically get the property information, but if you pass the property information yourself to the constructor, you can also create a wrapper for any other kind of data (including external data).
For the use case you describe, you can either use Sarnia or create a subclass of SearchApiExternalDataSourceController and use that to provide a new item type for your items. It's not supported out-of-the-box, but with a bit of code it's perfectly possible. And for D8, we can of course provide such an implementation in the Solr module itself, so no custom code will be needed anymore to support this use case.

rooby’s picture

Thanks for clarification re the entity api wrappers.

I did investigate sarnia briefly but there are a nuber of outstanding bugs and it is currently not being maintained.
I can also do what I need to do with a fairly small amount of custom code on its own, which will match my needs in this case a little better than out of the box sarnia.

I think the sarnia idea is very useful though and it would be good to see it make progress in both drupal 7 & 8.

drunken monkey’s picture

Status: Active » Fixed

So, I think we can call this "fixed". I don't think we rely on Drupal structure more than necessary, it should be relatively easy to write a datasource for external data and we'll probably do it in #2138837: Add more flexibility in how we show data in an index anyways (which should probably be moved into the Solr project once that has an 8.x branch).

Status: Fixed » Closed (fixed)

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