Is it possible to associate two types of content, and only show the other type of content in the block? Example: I have "content type a" and "Content type b" and I associate them. At the bottom of a "Content Type A" page I show the Associated Links block. It shows related nodes from "Content type b," but ALSO shows "Content type A" nodes. Can I exclude those?

Probably being able to access the results with Views would help. Maybe I can cook something up with Table Wizard.

Comments

emdalton’s picture

emdalton commented

What I tried to do was create a computed field that sets to the node type on save, then add a negative association between node types. I was able to add the association, but on my next screen refresh I got a long string of errors like this:

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 query: INSERT INTO associated_nodes_cache (aid, nid, associated_nid, score) VALUES in /usr/local/web/lamp/users/wsbe/site/sites/all/modules/associated_nodes/associated_nodes.module on line 403.

When I try to display one of the nodes that should be included in the association, I get this error:

Fatal error: Maximum execution time of 30 seconds exceeded in /usr/local/web/lamp/users/wsbe/site/includes/common.inc on line 634

Should Associated Nodes support computed fields?

emdalton’s picture

emdalton commented
Category: support » feature

My workaround was to create a plain text field on both of the content types and assign a different default value to each content type, then place a negative value association on that field. However, this is kludgy. It would be good if Associated Nodes could support contrasts between content types, and either support dynamic and computed fields, or document that they are not supported.

jfberroyer’s picture

jfberroyer commented

With Associated Nodes, you can associate together nodes of different types, but you can't associate node of type B only with node of type A only.
I had never thought about this, but I think it's a realy good idea and that will be a new feature in a next release.

For the CCK problem, I have never test the module with Computed Fields and I am not surprised that it doesn't work since the Associated Nodes plugin that is related to CCK looks directly in the database to find the information (for performance reason).

OpenChimp’s picture

OpenChimp commented
Title: One-way matches? » One-way Matches / Two-Sided Node Type Associations

I've just started using this module and love the potential I see in being able to configure different relationship types and use different citeria to define the strength of the relationships. Awesome Work!

I have a rather complex use case, which requires similar changes to what is described above. The website has various node types. Some are content related node types (Articles, Blogs). Other node types have actions related to them which we would like users to take action on. (Events [RSVP], Volunteer Opportunities, Non Profit [Donate, Support, etc.]). All of the content types are tagged with taxonomy terms (we have 2 taxonomies, one of which has a higher weight than the other, which is another reason I love this module). What I'd like to use this module to do is to provide a list of the action related nodes on the content related node pages - so, at the bottom of an article or blog, I would display a list of events, volunteer opportunities and non-profits which are found to have a strong relationship to this content.

Currently, for each node association, this module provides a single list of the node types to include in the association. I would recommend that this be divided into two columns allowing the user to create two-sided relationships.

Currently when I create the association, under Node Types, I select "article, blog, event, non-profit, volunteer opportunity". This module then needs to index the following node relationships:
article «» article
article «» blog
article «» event
article «» non-profit
article «» volunteer opportunity
blog «» blog
blog «» event
blog «» non-profit
blog «» volunteer opportunity
event «» event
event «» non-profit
event «» volunteer opportunity
non-profit «» non-profit
non-profit «» volunteer opportunity
volunteer opportunity «» volunteer opportunity

In the two-sided associations model, I would select "article, blog" on one side and "event, non-profit, volunteer opportunity" on the other. This module would then only have to index the following relationships:
article «» event
article «» non-profit
article «» volunteer opportunity
blog «» event
blog «» non-profit
blog «» volunteer opportunity

Obviously, for use cases which would still want to list associated articles on the article pages, you would just have to select the article node type on both sides of the relationship. The great thing about this module is that you could create both associations, and display the results in different blocks and even use different criteria determining the strength of the relationship.

I don't know what the best terminology would be to make this intuitive. It seems to me that it may be best to keep it very generic since each use case my be different, and the relationship goes both directions. By this, I mean that if I'm on a content node, I can use this association to list actions, and if I'm on an action node I can use the same index to list associated content nodes. Left Side, Right Side would be fine for me but I'm sure someone can do better. The important thing will be to provide some clear instructions so users understand the purpose of the two columns. I will see what I can do to provide these when I've had more time to think about it.

As can be seen above, aside from much better control of what type of related content to show for each node association, another benefit of this approach would be that many fewer relationships would need to be created. If I had a 100 content nodes and 10 action nodes, I think the current model would have to create ~6050 relationships [(110*110)/2] The two-sided model would only require 1000 [100*10]. This benefit becomes very significant when one side of the relationship contains much fewer nodes than the other ... 1000 content nodes and 10 action nodes would currently require over 500,000 relationships and only 10,000 with the 2-sided model. This should greatly improve the performance of building the index as there are much fewer relationships that need to be checked.

So ... I'm curious how much work you think it would take to implement this kind of change. What functions would be effected? Would you only need to change the indexing function or would you need to change the retrieval functions as well? What are your thought in general about this approach to solving this issue and of taking this module in this direction?

Note: An upgrade path for existing users would be simple - simply place the currently selected node types on both sides of the relationship.

tsi’s picture

tsi commented

Actually I believe this is another issue that Views integration will solve.