Use real Relationships instead of level magic in Views integration

thank your work.

how is going on this feature ?

subscribing

Subscribing

sub... this would mean I could add fivestar to search results right?

Ok, is there a patch anywhere to include fivestar ratings? I'm creating a reviews site, Thanks.

You can display fivestar in results already if you use the entity row style rather than fields.
However, you cannot sort or filter by fivestar as it does not implement the entity api.

If you want to go into further detail on this its really more appropriate in its own issue - and would need an issue in the fivestar queue to get anywhere useful with regards to sorting/filtering/etc.

EDIT: And now that I've looked at the queue I can see you've already done that #1256572: Integrate with Entity API

Subscribing. I've been trying to build today a search view that needs this. I'll do some testing as soon as it's working.

Thanks.

subscribing

subscribing

subscribing

i applied the newest patch with git apply -v patchname.patch somehow git applys not all....testing with pact p1 again.

Works like a charm for a very simple setup, I'm trying now to use it on an existing site but everything breaks when the patch are applied.

Is a upgrade path needed for any of the two patches (entity, search_api)?

I got several PDO sql exceptions but I didn't saved the text to paste it here.

I'm trying another approach now. Uninstalling search_api, upgrading entity, upgrading search_api, enable search_api again and build the view form scratch. I'll report later how things are going.

I got several PDO sql exceptions but I didn't saved the text to paste it here.

I'm trying another approach now. Uninstalling search_api, upgrading entity, upgrading search_api, enable search_api again and build the view form scratch. I'll report later how things are going.

subscribing

After this patch I would expect that any view that can be build without using a search index as a base table can also be build using the search index as a base, since you can fetch the referenced entity.

It is not true for the view I'm trying to build. It involves entityreference fields. Looks like the relationships support of entityreference fields is not working when I build the view using the search index.

I got the following data structure.

* Entity type: THINGS
* THINGS have an entityreference field pointing to content type A
* There is another content type B that has an entityreference field pointing to entities of type THINGS.

Without using search api, I can build a view that:

* Lists THINGS
* Prints the node title and fields from the referred node (type A) (Using entityreference views relationship support)
* Prints the node title and fields of nodes of type B that are referrencing each THING. (Using entityreference *reverse reference* views support).

When building the same view using the search index I cannot build such a view since the relationships options that Entityreference provides are not available in the views relationships interface.

So when building the view without search api I see the following options in the relationship dialog:

Entity Reference: Referenced Entity (A bridge to the Content entity that is referenced via field_referred_node)
Entity Reference: Referencing entity (A bridge to the Things entity that is referencing Content via field_referred_node)
Entity Reference: Referenced Entity (A bridge to the Things entity that is referenced via field_referred_thing)
Entity Reference: Referencing entity (A bridge to the Content entity that is referencing Things via field_reffered_thing)

None of these options are available when building the same view using the search index.

Let me know if you need more info.

Here is #24 rerolled to work with 7.x-1.x

Am I right that the patch contains a "forecast" of this #1260812: Move "Database search" into its own project?
The patch deletes all the contrib module search_api_db.
Next guess, the removed module can be found here soon: http://drupal.org/project/search_api_db

Just applied latest patch from here and synced to the latest entity views branch.
I discovered that if the search index is out of sync I get this notice:

Notice: Undefined offset: 163 in entity_plugin_row_entity_view->render() (Line 106 of modules/entity/views/plugins/entity_plugin_row_entity_view.inc).

This further leads to this nice exception - an thus to a broken site:

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (Line 7414 of drupal/includes/common.inc).

It looks like this could be fixed in the function render() of entity/views/plugins/entity_plugin_row_entity_view.inc by changing this condition:
if (isset($id)) {
to this:
if (isset($id) && isset($this->entities[$id])) {

But I'm not sure if this is the (only|right) place where this kind of sanitization should take place. Has the search_api a good way to check wheter an entity id is still valid?

All other stuff looks very good - after reindexing :)
Thank you very much!

Hey Thomas,
one of my views still throws some notices which I think are caused by this patch:
Undefined property: SearchApiViewsQuery::$group_operator in SearchApiViewsQuery->build() (Zeile 157 von search_api/contrib/search_api_views/includes/query.inc

from http://drupal.org/node/1266036#comment-5106500 and according to Thomas, related to this issue

There is one use case I still couldn't get working:
I have a Search API index with field collections. Additionally I have my own entity property from a field collection to a profile2. Adding this relation in Views basically works, but when using a field that is based on the views_handler_field_entity handler (e.g. Rules Link in combination with the patch in #1264258: Update to latest views changes), errors are thrown and no values are displayed. Following code in pre_render
list($this->entity_type, $this->entities) = $this->query->get_result_entities($values, !empty($this->relationship) ? $this->relationship : NULL, $this->field_alias);

seems to ignore the relationship (although it is correctly set in $this->relationship) and returns the field collections instead of the profiles.

hm, no, it still doesn't work.
From what I can see $this->query->get_result_entities() just returns the profiles (now correctly), but misses the entity type.

Well done, Thomas. My use cases (which are quite complex) seem to work now. Once the Entity API Views stuff is committed, I would say this is ready as well.

from the entity api issue:

>Of course, since they are from different base tables. Nothing we can do about it, I'm pretty sure – >Views just isn't really suited for our use cases (although I consider this behaviour rather confusing in >normal Views, too – in my opinion, the group shouldn't list the base tables, but also directly the >relationships, as I did it in my previous Views integration).

Ouch. I had another look and indeed each field only works with one of the base tables. That's a real UX nightmare though, so we need to find a solution here somehow. Changing how Views does it is probably out of scope and I think it basically makes sense as it keeps the amounts of fields to select lower.

So maybe we should just fix the names of the search api index fields to be named differently? E.g. "Indexed node: Title"?
Related but a minor thing is, that the base-table name is just named like the index. If you choose "node" as index name choosing base tables is going to be confusing. I'd suggest using "Search API: index name" there. So maybe "Search API Index name: Field name" would be a good naming for fields too then? Well, that would be belong into the search api issue then.

-> We need to solve this UX problem.

#44 does not apply cleanly for me with the latest dev code.

In order to get the multi load functionality for base entities working, entity_load() must be called before EntityFieldHandlerHelper::extract_property_multiple() is used in get_result_wrappers().

Something goes wrong in #47. It seems to multi load the entities, but doesn't display them any more (in my view only one row out of 3 is shown, in another view all rows are display, but the values of a related field are missing).
Adapting patch from #43 by moving the entity_load() call up in get_result_wrappers() works as expected.

yep, like this. but I think we can remove the check for the static cache, as done in #47.

So I'm curious about this issue and whether it's related to a something that's "missing" in my available fields in my View.

I've built out a view against a content index.

This view contains a relationship for a Drupal Commerce product reference against the listed node.

After adding this relationship, I can add fields for all of the Drupal Commerce fields except the "Add to cart" form. Under a normal Content view, this field is available and works great through a product reference relationship. It's only when the source is for the view is a Search index that this problem arises.

I'm using all of the latest -dev versions of Search Api and related modules. And I've applied that patch in #51 since it's not included in the current -dev.

I would have created a new issue, but it seems this must be related to this issue. Considering after I read this entire issue I saw someone mention that the bottom line with this patch was that you should be able to recreate any view from the search index that you can build with a normal view - if it's working correctly.

Let me know if there is any technical data I can provide.

Let me just say that this project is epic, and I am "this" close to basically developing a full e-commerce site that rivals Newegg in searching and filtering options contextually for each section thanks to this module. This is the last little piece...lol. Thank you for all that you do, it's amazing.

Great to have this finally committed :) Patch from #51 works as well.

Concerning #52, I guess Drupal Commerce doesn't yet use the generic field_entity handler with the view entity tables (see #1270890: provide a way to provide entity-related views fields for more info).

I was afraid it might be an issue with Commerce, although I had hoped that since it works fine under a normal view that it would work with the Search index.

I'm not trying to pull the add to cart form off a search indexed field. I've added a new relationship to the view for the Content: Product and it is off of that relationship that I should be able to add the add to cart field.

I'm sure you already knew that though and I'm just going to have to wait for this to be resolved another way.

Ok, thanks for responding and giving me some clues on where to go with this. Otherwise, this system is working really nicely. Great work!

I hate to post in this issue again, but I'm not sure if this is related or not...

If you add fields to the index via the "Add related fields" dialog in the admin and then have them indexed, you of course can access those fields as normal fields in views... What I'm not seeing though, is a way to allow those fields to be a part of a views Sort. They simply just don't show up in the Sort section of views, even though I've set them as string or integer and they are single value.

I'll create a new issue, sorry.

Have you created a new issue? I can't find it and i have exactly the same problem like #57.

OK, the relation was not single-valued and this is not support i guess.