How is this different from nodereferrer?

The Node Referrer module provides a CCK field that is used to store information about the Node Reference field in another node. Hence it duplicates relationship information, which is prone to generate inconsistencies.

On the other hand, the Reverse Node Reference module provides a Views relationship that uses the information of the original Node Reference field to join both nodes, from parent to child. Note that Node Reference itself provides a Views relationship that can be used to join from child to parent. In fact, what this module provides would have to be part of the Node Reference module itself. However, it has been like that due to compatibility issues with MySQL, as detailed in the project page.

Background and discussion about this feature in the CCK issues queue: #241078: Reverse node-reference views relationship

When it comes to the feature that renders a report of back references in the node view of parent nodes, this can be done using the Node Relationships module, that also exploits the current relationship data managed by the original Node Reference field to render this report on parent nodes using a fully customizable view, and with no need to duplicate relationship information.

PS: Project page updated. See the Diff.

Keeping track of this thread...

Still uncertain what we could do with this module, we'll have to try it out. Subscribing ;)

I apologize for re-opening this issue, but I needed a clarification. Are you saying that Reverse Node Reference and Node Relationships provide similar functionality? The Node Relationships module has a link recommending this module, and I am attempting to discern whether one, a combination of both, or neither of these modules can provide the functionality I'm looking for.

I have a content type - let's call it A - which is referenced by a number of other content types - let's call them B, C, and D. On a node of content type A I wish to display a block containing all nodes of type B, C, or D which reference that particular A node. I would group the results as an HTML list so that the sidebar of any given A node would have a block showing:

B
- b1
- b2
- b3
C
- c1
- c2
- c3
D
- d1
- d2
- d3

I very much appreciate any guidance/clarification you can provide.

Re: "Are you saying that Reverse Node Reference and Node Relationships provide similar functionality?"

No. Each module provides a different set of features that allow you to approach similar problems in different ways. It is all about relations between nodes, but there are several problems here to solve. There is no single module that allows you to solve all your needs about relations between modules, the way users manage them, the ways you display them, etc.

Re: "The Node Relationships module has a link recommending this module..."

That's because the Reverse Node Reference module is pretty related to the Node Relationships module. The former provides a method to create joins in views that allow you to do things the later cannot do.

Re: "I have a content type..."

Talking about your particular use case is not the same as talking about differences between modules, which is more generic, and the purpose of this thread.

In summary, if the module descriptions do not help enough, I would suggest trying all these modules in a dev environment and then you'll be able to see for yourself which one fits better your particular needs. Then, if you think the module descriptions need clarification in one way or another, opening a separate feature request about that would be much appreciated. Thanks

1. Generic descriptions are only useful in the context of case examples. There is a reason learned people from Jesus to Einstein use parable and allegory to elucidate their points. The best way to understand something is to see how it applies to a hypothetical situation.
2. You basically told me to RTFM or to figure it out myself. This embodies everything people hate about the open-source movement, from Drupal to Linux (and believe me there are things I love about open-source as well). Most FOSS developers like to say "I made an awesome thing! And if you're not a developer too and can't figure it out on your own, well... HAHAHAHAHAHA!!!" "TFM" which I'm supposed to read is usually scant and written by programmers for programmers, and telling me to poke around until I understand it is the same as telling me to bang my head against a wall for a few hours until it bleeds. All I wanted to know was how/if each module would provide the desired outcome BEFORE investing HOURS AND HOURS figuring out how the hell they work.

It would be nice to wake up one morning to a "Drubuntu" type community, where people actually try to make the software easy to use and understand. Until then I guess I just keep wasting days and weeks of my time exploring arcane dead ends and asking questions until someone feels like being helpful.

You could also hire someone else with the proper skills/knowledge.

Coding requires time and resources, that means money. Isn't enough to share code and try to keep the module up to date with fixes as time permits? Open source does not mean someone else is going to resolve all your doubts about the software. Maybe one day all users of the software will also share the things they learn, in a way that you won't need to ask things like this. Sadly, people gets the things and goes... not everyone shares here. That's life. It isn't perfect.

Sometimes, open source needs help from every possible source. You could also help improve the documentation, or create a new page in the Drupal handbooks to share the concepts you learn while testing these modules. Maybe someone else did the same you could do now, but no one shared that before. You could help being one of the people that spends their time trying to add value, rather than complaining, because in the end, I do not have time to answer every single question about this module.

I'm open however to enhance the documentation in the project page, or in the module itself, with yours or anybody else's suggestions, if these come in a way that can really add value and help others.

Fair enough. I understand FOSS developers do this for free in their own time, and they have to prioritize. All I'm saying, from the perspective of a professional technical writer (among other hats I wear), is that releasing software without documentation is like handing out guns and ammo without instructions. It's somewhat irresponsible. I'd be happy to improve the documentation on a number of Drupal projects if I could get some actual explanation from the developers rather than having to spend countless hours reverse-engineering the interface to understand it myself. I have never built a client's website or developed a procedure without painstakingly documenting the entire usage process for the end-user and testing that documentation on as wide a base as possible. I would never toss something at a user and say "figure it out. Write your own documentation if you want to."

Anyway. happy coding.

This is culture clash. Drupal drifts more and more in the 'framework' direction which requires coding skills to make real use of it. Weak advice from a non-coder: Programmers tend to put much documentation into the code, be it comments, the structure of the code or the naming of variables. I don't like this either, but if we want to use FLOSS we simply have to to deal with it (i.e. learn to read the code, and learn from trial & error in dev environements). If this is economically viable is another thing, but rest assured that Markus' work is anything but "irresponsible" ;)

And please keep in mind that you're being paid when you build a client's website. If you pay Markus to write a manual I'm quite sure he won't refuse, and I'm not sure how much of your painstakingly accurate documentation you have published as Open Content. It's still quid pro quo, right?

-asb

I know this is a complex issue. This module needs additional documentation with examples where to show off different use cases where this Views relationship can be applied. My problem is that I do not have the time for that, and that's why in the project page there is a section labeled "How can you get involved?" with a note that reads "Help writing documentation. Please, open a project issue if you wish to help writing documentation for this module".

My intention in posting this module was to provide a valid solution to a problem that was requested in the CCK queue. See #241078: Reverse node-reference views relationship. I even tried to share this effort with someone else, because I knew I do not have much time. If I do not have the time to write more documentation for this modules, also means that I do not have time to fight against particular use cases posted in the issue queue trying to provide particular solution to single problems. That's something that could be approached with more documentation, but who's going to write that? Who's going to answer all the questions that people post in the queue?

While we may wait patiently for more and/or better documentation, I still need to provide an answer to those like you that keep posting questions. But since my time is limited, I tend to be as honest as possible. My experience says that's easier to find answers in the development forums, than posting in the issues queues of the modules. There are hundreds of issues lost in these queues, unanswered or badly addressed. How can that be solved? Life isn't perfect. If you want a better place to live, try to add your own bit, maybe writing docs where devs do not have enough time. If more people did like that, we would not be talking about it right now.

I could have just wrote this module for our project, and ignore the requests in the CCK issues queue. I already tried to be helpful with others, and I do not ask nothing in return, I just love to share when possible, it's part of me. It sounds like you're telling me that I should do even more, but I have limitations...

@Markus: Please don't waste any more time with this; it's pretty simple - you're being paid to write a module and then give it away for free to the community; canadrian takes it for free and is being paid by his/her client for using it, but complains that he has to invest some time to understand it because not all modules are presented on a silver platter. So let's see if canadrian cares to give something back for being able to use all these free modules. At least I would feel much more motivated to think about his use case if he would share some of his work, e.g. at his business website or in the handbook pages on d.o, as others do ;)

Please keep up your exceptional work, Markus!

Greetings, -asb

Wow this went off topic quickly ;-)

Back to the subject of the matter...

In your first reply (comment #1), you said:

The Node Referrer module provides a CCK field that is used to store information about the Node Reference field in another node. Hence it duplicates relationship information, which is prone to generate inconsistencies.

Unless I've misinterpreted this, I'm not sure what you say is true. It appears to me that both modules are solving the same problem with slightly different tools; You're using Views and Node Referrer uses native SQL.

See this:
http://drupalcode.org/viewvc/drupal/contributions/modules/nodereferrer/n...
(nodereferrer.module, 6.x-1.0-RC2, Line 368)

This is the function which generates the list of referring nodes.

Your method, using Views, seems to provide better theming and configuration options (such as output type), however Node Referrer would be more lightweight as it doesn't depend on Views; it simply queries and renders using a single theme function.

Does that sound a fair summary or have I missed something?

@asb: Thanks :)

@nicholasThompson: hmm... no. AFAICT, the Node Referrer module creates another Node Reference field for node types in "the other side" of the relationship, and then it tries to synchronize those fields as node references are created. Then, the user can use regular Node Reference integration with Views to create queries that join nodes using any direction of the relationship. But that means the same information that links one node with another is stored in two separate Node Reference fields. ie. the information that holds the relationship is duplicated in two different places, hence it is prone to inconsistencies.

On the other hand, this module is able to provide the same functionality in Views, but it uses Nested Joins, which is a technique that is not fully supported in MySQL until 5.1. That is why this Views relationship was not included in CCK itself.

In other words, with Node Referrer module it works like this:

- Content type A has a Node Reference field to Content Type B. Let's say this field is named "A2B".
- Node Referrer module manages another Node Reference field in Content type B automatically. Let's say this field is named "B2A".
- When the user creates a relation using the "A2B" field, Node Referrer module automatically updates the "B2A" field.
- Now it is possible to create Views that link nodes from type A with nodes of type B using the Views relationship provided by field "A2B".
- It is also possible to create Views that link nodes from type B with nodes of type A using the Views relationship provided by field "B2A".

With the Views relationship provided by the Reverse Node Reference module, you do not need the field "B2A" because it can do the same in Views using the information stored in field "A2B".

There are more pros and cons to evaluate in these differences, because the user will see a Node Reference field in both sides of the relation when editing, for example, and this might be good or not, depending on the use case, and the cardinality of the average relations (there may be node reference fields with hundreds of multiple values, pretty hard to edit).

depending on how both modules are supported, the amount of users and how things evolve (like MySQL 5.1 or PostgreSQL 8 support on providers), it seems like this module will eventually deprecate completely Node Referrer

First I appreciate all the effort put into this module.
Second, does this module also work for user reference fields?

sub

subscribing

Thank you for this thread, I was getting really confused between the 3 modules which allow to make backreferences. I tried them thoroughly, and here is what I got from various tests and this thread, from my non-developper point of view:

Node Relationships : Makes it ultra simple by providing the 3 preset displays of backreferences (Tab, Page, Field). Is mostly adequate for the basic need of having backreferences displayed on a node. Also helps keep track of references through nice diagrams.

Content Reverse Reference : allows to really create complex views with multiple reverse references, provides crazy flexibility such as reverse relationships on arguments, nested reverse relationships,...

Nodereferrer : The major difference has been pointed out very nicely by markus_petrux :"a user will see a Node Reference field in both sides of the relation when editing, for example, and this might be good or not, depending on the use case, and the cardinality of the average relations (there may be node reference fields with hundreds of multiple values, pretty hard to edit)." This is so important in the process of choosing one or the other solution. It has the problem of duplicate fields, and it does not provide as much flexibility as Content Reverse Reference (At least, I've not been able to replicate all the complex views).

I still have a question: regarding a basic backreference view that can be done with both Node Relationships and Content Reverse Reference: which module provides the best performance?

PS1: Maybe this summary is a bit useless and incomplete, but it's what I would have love to read when I first went into this reverse relationships things!
PS2: Suscribing for user relationships too! But there is already a dedicated thread here : http://drupal.org/node/1139116

subscribe

Subscribing