Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.hello Thomas
I've been struggling with this for a while & need some help
I have 2 tables say A joined by node reference with B
I'm interested in using the facets aspect of solr
I've watched your video zillion times & have followed it & it works for me to a point
First using the views module I can get direct attributes of table A but not the attributes of B
I believe the way to do it using relationships in view
However when I click on + to add a relationship it says "There are no relationships available to add."
I came across this: http://drupal.org/node/985512
I'm wondering if it is possible at all
If yes could you tell me what additional modules I need to install to make it work on drupal7 with solr
Once I can get past being able to display B's attributes in the search result, I want to define some of them as facets as well
thanks in advance
Anindita
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | references.node_type_property.patch | 1.16 KB | drunken monkey |
| #5 | testSearch.JPG | 76.96 KB | anindita |
| #5 | test.JPG | 77.83 KB | anindita |
| #4 | index.JPG | 39.71 KB | anindita |
Comments
Comment #1
drunken monkeyIt depends on how your tables are related, and whether / how this relation is exposed. The Search API uses entities and the Field API for finding properties and relations. If the relation is properly exposed through the Entity API or the Field API (as a property or field of type "node"), then this should work out of the box. Otherwise it doesn't work, so you would have to expose the relation to the Entity API yourself. See the documentation for
hook_entity_property_info()(in the Entity API module) for details.Comment #2
anindita CreditAttribution: anindita commentedthanks Thomas, a little more help needed
I have 2 content types
1. Parent node with attr parent_attr(text) & child(node ref to child node)
2. Child node with attr child_attr(Integer)
I have 2 instances of child node -child1 & child2
& 2 instances of Parent node - parent1 (references child1 & child2) & parent2(references child2)
I create a regular view
define my relationship on child & choose fields child_attr & parent_attr
what I get is :
title child_attr parent_attr
--------------------------------------------
Parent2 102 parent2_attr
Parent1 101 parent1_attr
Parent1 102 parent1_attr
Now I create my solr index view
I cannot add the relationship (because solr is not relational ?)
I want parent_attr & child_attr as facets & want to filter on node:content_type=Parent
I want my output to look like
Title parent_attr child child_attr1
--------------------------------------------------------------------------
Parent1 parent1_attr child1 101
Parent1 parent1_attr child1 102
Parent2 parent2_attr child2 102
How do I do that ?
If I don't set the node type filter, only then I get child attr as facet like below:
Title parent_attr child child_attr1
--------------------------------------------------------------------------
child1 0 101
child2 0 102
Parent1 parent1_attr child1, child2
Parent2 parent2_attr child2
The child attr is seen only when it is on a different line i.e. when we are showing a node of type child
I want to be able to drill into child to get to its attributes to display as part of search result & search facet
IT is possible right ? is there any limit to the number of levels I can drill into ?
or do I have to artificially add additional columns in parent node to capture child attributes
I hope I was able to convey what I wanted :)
My solr search index is called solrIndex, which appears in the dropdown list for 'Show' & that is what I use to create my faceted view (Please confirm this is the right choice)
thanks again
Anindita
Comment #3
drunken monkeyThe solrIndex is the right choice for the view, yes. With Search API views, you don't have to add relationships, however – the fields should already be there. If you select the "add" link next to "Fields", you should see some fields prefixed with "child: " – you should also be able to filter on it (with the "Filter" select box in the upper right, when adding fields).
For having the attributes of children available as facets, you'll have to index those attributes. Go to the "Fields" tab for the index, open the "Add related fields" select box and select the "child" field. The child's attributes will then appear in the field list (prefixed with "child »") and you can index them. You can then create facet blocks for them, or use them as Views filters.
If none of this is possible, the fault is in the module providing the node reference field, which seemingly doesn't support the Entity API. In that case, please create an issue there.
Comment #4
anindita CreditAttribution: anindita commentedthanks Thomas
When I click on the '+' next to fields:
Yes I do see some child attributes, but I do not see the one I want namely child_attr
i.e I see it as Node:child_attr1 which is what I selected but it does not get populated with value
but not Child:child_attr1
see list below for what I get when I filter on child
Also checked my search index, I'm indexing both child as well as child_attr (Please see attachment
Is there something wrong _
I am using all latest packages
thanks
Anindita
++
Filter
Author: Created
The date the user account was created.
Author: Edit URL
The url of the account edit page.
Author: Email
The email address of the user account.
Author: Last login
The date the user last logged in to the site.
Author: Name
The login name of the user account.
Author: URL
The URL of the account profile page.
Author: User ID
The unique ID of the user account.
Author: User roles
The roles of the user.
child: Author
The author of the node.
child: Comment count
The number of comments posted on a node.
child: Comments allowed
Whether comments are allowed on this node: 0 = no, 1 = closed (read only), 2 = open (read/write).
child: Content type
The type of the node.
child: Creates revision
Whether saving this node creates a new revision.
child: Date changed
The date the node was most recently updated.
child: Date created
The date the node was posted.
child: Edit URL
The URL of the node's edit page.
child: Is new
Whether the node is new and not saved to the database yet.
child: Language
The language the node is written in.
child: New comment count
The number of comments posted on a node since the reader last viewed it.
child: Node ID
The unique ID of the node.
child: Promoted to frontpage
Whether the node is promoted to the frontpage.
child: Published
Whether the node is published.
child: Revision ID
The unique ID of the node's revision.
child: Revision log message
In case a new revision is to be saved, the log entry explaining the changes for this version.
child: Sticky in lists
Whether the node is displayed at the top of lists in which it appears.
child: Title
The title of the node.
child: Translation source node
The original-language version of this node, if one exists.
child: URL
The URL of the node.
child » Author: Created
The date the user account was created.
child » Author: Edit URL
The url of the account edit page.
child » Author: Email
The email address of the user account.
child » Author: Last login
The date the user last logged in to the site.
child » Author: Name
The login name of the user account.
child » Author: URL
The URL of the account profile page.
child » Author: User ID
The unique ID of the user account.
child » Author: User roles
The roles of the user.
child » The main body text: Summary
(No information available)
child » The main body text: Text
(No information available)
child » The main body text: Text format
(No information available)
child » Translation source node: Author
The author of the node.
child » Translation source node: Comment count
The number of comments posted on a node.
child » Translation source node: Comments allowed
Whether comments are allowed on this node: 0 = no, 1 = closed (read only), 2 = open (read/write).
child » Translation source node: Content type
The type of the node.
child » Translation source node: Creates revision
Whether saving this node creates a new revision.
child » Translation source node: Date changed
The date the node was most recently updated.
child » Translation source node: Date created
The date the node was posted.
child » Translation source node: Edit URL
The URL of the node's edit page.
child » Translation source node: Is new
Whether the node is new and not saved to the database yet.
child » Translation source node: Language
The language the node is written in.
child » Translation source node: New comment count
The number of comments posted on a node since the reader last viewed it.
child » Translation source node: Node ID
The unique ID of the node.
child » Translation source node: Promoted to frontpage
Whether the node is promoted to the frontpage.
child » Translation source node: Published
Whether the node is published.
child » Translation source node: Revision ID
The unique ID of the node's revision.
child » Translation source node: Revision log message
In case a new revision is to be saved, the log entry explaining the changes for this version.
child » Translation source node: Sticky in lists
Whether the node is displayed at the top of lists in which it appears.
child » Translation source node: Title
The title of the node.
child » Translation source node: Translation source node
The original-language version of this node, if one exists.
child » Translation source node: URL
The URL of the node.
Global: Custom text
Provide custom text or link.
Global: Math expression
Evaluates a mathematical expression and displays it.
Global: View result counter
Displays the actual position of the view result
Image: The Alt attribute text
(No information available)
Image: The image file.
(No information available)
Image » The image file.: File ID
The unique ID of the uploaded file.
Image » The image file.: File name
The name of the file on disk.
Image » The image file.: File size
The size of the file, in kilobytes.
Image » The image file.: MIME type
The MIME type of the file.
Image » The image file.: Owner
The user who originally uploaded the file.
Image » The image file.: Timestamp
The date the file was most recently changed.
Image » The image file.: URL
The web-accessible URL for the file.
Node: Author
The author of the node.
Node: child
Field field_child
Node: child_attr1
Field field_child_attr1
Comment #5
anindita CreditAttribution: anindita commentedhello thomas
One reason why I cannot really blame the entity api / node ref part is because when I build a regular content view, I see the child attributes being displayed correctly
Pl refer to attachment
http://172.19.166.78/drupal7/test regular content view where I see child_attr
http://172.19.166.78/drupal7/testSearch search view where I do not
The package dependency chain is
references CTools Views Entity search_api search_api_solr
references provides node-user references + is that what you meant ?
Do I need any other modules ?
thanks
Anindita
Comment #6
drunken monkeyThis is a different thing altogether and doesn't mean anything.
However, since you have the "child" and "child_attr" fields correctly listed for the index, there really seems to be no fault with the other module.
One error I saw is that you shouldn't set "child_attr" to "indexed" on the "Fields" tab, but "child » child_attr". As said, go to "Add related fields" at the bottom and add the fields of the "child" entity. Then you should get several fields of the child into the list. Once "child » child_attr" is set to "indexed", it should also appear in the Views filters list.
In the Views field list it should already appear now. When it appears on the index's fields list, I don't see a reason why it shouldn't …
I have an idea what could cause this, will test later today.
Comment #7
drunken monkeyOK, I can confirm now that this is indeed a bug. Thanks for spotting this!
The problem is that when fields are set on bundles, and not on whole entities (as is the case with nodes, and e.g. also taxonomy terms) the fields aren't automatically includeded in the property list. For building the field list for an index (and also the fields that will be available in Views) I manually include them by specifying a property alter callback and use
entity_get_all_property_info(). However, I do that only for the "main" entity, that gets indexed, not referenced entities.Therefore, the referenced entities only have their normal properties and those fields, which are set on the whole entity type (e.g., the node body), but not fields set on the bundles.
I'll have to fix that somehow.
Comment #8
anindita CreditAttribution: anindita commentedthanks a lot Thomas, really glad to hear that I could convey my issue and you know how to fix it. I feel fairly relieved coz this is awfully important milestone to cross for what I am doing and we chose Drupal apart from its other strengths solely because of this cool faceted search feature.
Not very sure of what you mean by entity Vs bundle
Node is an Entity, User is an Entity etc
Parent and Child are content types of entity type node
Are you referring to Parent and Child as bundles ?
Is your fix going to take care of multiple level nesting
grandfather parent child
So I can index grandfather attributes parent and child attributes and they will be available int he view and as facets ?
I will await your fixes
thanks again
Anindita
Comment #9
drunken monkeySorry, that part was more of a technical explanation for other developers who might be able to help with this. Yes, Parent and Child (i.e., content types in general) are bundles of the Node entity type.
Since you have only a relation from parent to child, and not the other way round, you can't index a parent's or grandparent's attributes. But yes, the other way round it is possible, if you mean that. So you could both index and display e.g. "child » child » child_attr".
Comment #10
anindita CreditAttribution: anindita commentedHmm maybe the fix is not straightforward then
is it doable though in a few weeks
In case it is not possible to do it via bundles, is there a different approach I can take to get around this
The link to example of job listing is very slick and shows multiple table levels, so can I get past this issue by somehow making Parent and Child seem like Entities instead of Bundles ?
no I was not referring to inverseOf relation,
rather accessing child attributes more than 1 level deep and I think your fix will address it
thanks
Anindita
Comment #11
drunken monkeyIt should be doable in a few weeks, yes. I just want to try to come up with a good solution, not just any one – but a simple fix will very probably be possible, if all else fails.
And no, there is probably no easy way to work around this, without adding custom code – and when you do that, you could just as well fix it on your own.
Comment #12
drunken monkeyJust talked with fago about it, and we should probably wait for #1077148: add an entity-view row plugin, as those field handlers will then probably be used by the Search API, too. Maybe this will already fix the problem, or we can then solve this permanently.
He also said that modules can directly specify the bundle when specifying a relationship, which could be an appropriate solution in this case. However, the References module currently doesn't seem to support this. Could you try whether the issue is fixed after applying the attached patch to the References module?
Comment #13
drunken monkeyComment #14
muschpusch CreditAttribution: muschpusch commentedWorks like charm! Thank you!!!
Comment #15
drunken monkeyOK, then let's see what the guys in the References module think about this.
Short summary: This patch adds information about the bundle / content type of a node reference, if only a single one is possible, which can then be used via Entity API.
Comment #16
yched CreditAttribution: yched commentedI'm not familiar at all with Search API, so I'd welcome a short summary of what the patch brings to the table, in generic, non-Search-API related terms :-)
Also, I'm not sure the approach floats. From what I can understand, the patch helps Entity API qualifie a value of a noderef field as "[a reference to] a node of type foobar". It does so by picking the first of the 'referenceable node types' from $field['settings']. Well, that's simply incorrect, since there can be several 'referenceable types', so a given noderef value can represent a node of any of those types, not just the first.
Moreover, #945004: [release blocker] Missing views-mode for picking userreference and nodereference just re-added the noderef D6 feature of being able to specify the list of referenceable nodes using a view - in this case, the referenced nodes can be of any type that the view can select, which, from noderef's point of view, is pretty undecidable.
Comment #17
Shadlington CreditAttribution: Shadlington commentedI think it just gets the node type when there is only one referenceable node type.
So it wouldn't be 'wrong' when there are multiple types, it just wouldn't do anything.
Comment #18
drunken monkeyOf course that would be incorrect. As Shadlington wrote, that's what the
if (count($field['settings']['referenceable_types']) == 1)is for.OK, I didn't know about that, but seems like you could just do nothing then, as well. Just add code for detecting this case (don't know how to do this, myself) in
node_reference_field_property_callback()and let it return without doing anything if that is the case.Comment #19
yched CreditAttribution: yched commentedDoh. I guess I was a little tired last night :-p.
I'm not opposed to this patch, but I'm a little bugged by the lack of consistency - metadata that will "sometimes be there, sometimes not".
This 'bundle' (i.e 'type of the referenced node') meta info will be relied on by an unknown amount of features (Search API facets now, probably other stuff in the future). This means that all those 3rd party features down the line have an unspoken dependency of "oh, btw, it will only work if your noderef field is configured to reference one single node type through the 'referenceable types' checkboxes". Not very friendly or predictible for the end user, and we have no good UI mechanism to convey that info.
Comment #20
drunken monkeyI understand your concerns, I guess this really isn't ideal. However, the metadata information is designed that way, so it can either be there (when only a certain bundle is referenced) or not. Therefore, this is certainly the way to use it, and other modules definitely shouldn't depend on this information being there – they are just able to use it (and Entity API itself will, for its metadata wrappers) if it is present.
As far as users are concerned, this issue demonstrates that even currently users will wonder why some properties of referenced nodes aren't found. This patch would fix this in at least some cases. For the others, I guess the Entity API will have to deal with it somehow – however, the fix here would be necessary anyways, for a result as correct as possible.
Comment #21
anindita CreditAttribution: anindita commentedhello Thomas and all
I don't fully follow the chain here, so bear with me
1) if Parent has only one node ref to node content type child1, this will work ?
2) But if it has multiple node ref to content types child1 & child2, then this patch will not work ?
For me, it is case 2 i.e. my main node type has multiple node type references to other node types
I really need this for my faceted search to be effective - Is there any other way we can get around this ?
thanks
Anindita
Comment #22
drunken monkeyYes, this only works for referenced nodes of a single type. Sadly, the solution for more types isn't that easy.
Hm, I probably shouldn't have moved this issue but created a new one in the References module, as we now need another one in the Search API or Entity API issue queue … But please create another one there. I contacted fago (again) to see how we can solve this for the Search API.
Comment #23
tnightingale CreditAttribution: tnightingale commentedI believe this issue is now fixed with latest latest version of reference and dev versions of entity and search api.
There seem to be quite a few parallel threads on issues relating to this. For reference I think these seem to be the *main* contributing fixes: #1214974: Provide a way for the wrapper to alter the property info of referenced entities and #1214862: Custom fields not available on referred contents
Comment #24
tnightingale CreditAttribution: tnightingale commentedWhoops! sorry didn't mean to set as active. Leaving as "needs review" so someone more familiar with this issue can confirm.
Comment #25
drunken monkeyAh, yes, this should be solved now!
anindita, please re-open if you still experience this problem with latest dev versions.