nodereferences with single instances

See http://drupal.org/node/474626

I'd like to open this ticket back up. In my opinion, the current solution for single-instance fields is not a good solution. It's counter-intuitive to require users to choose "unlimited" (multiple) when they really want a single-instance node reference field. In other words, in order to make CNR work, you have to change the way users configure Node Reference fields. Additionally, it will be confusing on a node form, because users will see a multiple field, when they should only see a single-instance field. Lastly, it will present data integrity issues down the road, since it is possible that a user would add more than one value on the node form.

You said here that you can't handle single-instance fields because they are their own content_type_x table. However, if you first query the content_node_field table for all "nodereference" types, and then query the content_node_field_instance table to figure out which content types are using that node reference, you should be able to properly detect the 1-many relationship. Does this make sense?

It makes sense, but there is one problem.
Some extra logic needs to be in place to counter the overloading of references problem -> which is when one reference instance only allows 2 reference and for example 3 nodes try to reference to it then 3 refs would be created to the three nodes trying to reference to it
I ll see what i can do in the next release.

Let cck handle how much references to use.
Remove the checkboxes and remove the form alter.
Add the logic to counter overloading references.

With #730986: Refactor to use content module's data APIs in, there's probably no strong reason anymore to require multiple references.

What we need, though, is to decide how to handle the case that a second reference is added to a node that has a single-value field. Options: (a) throw an error on validation, preventing the second reference or (b) remove the existing reference on both sides and replace it with the new one. Likely (a) is most straightforward. Draft error text:

t("@title already has a reference and only a single reference is permitted. Before adding a reference, you would need to <a href="%url">edit</a> @title to remove the existing reference.", array('@title' => $node->title, '%url' => url('node/'. $node->nid)));

Perhaps rather than the type of error message above, might it be possible to use information from the fields in content types to infer cardinality?

For instance, I have a site where quiz content must be linked to course content. This is done as a 1-to-1 relationship: one course has a maximum of 1 quiz, and the reverse is also true.

Because my node reference fields are both single, we know that the cardinality is 1-to-1, so the following scenario becomes possible: course A is linked to quiz 1. Now, linking quiz 2 to course A would reverse-link course A to quiz 2 *and* remove the link from quiz 1 to course A, effectively "orphaning" quiz 1. A notice might come up to that effect.

Let's say, now, that we define the course to quiz relationship as a 1-to-n relationship. This would be done by making the node reference field in course unlimited but leaving the node reference in quiz to a maximum of 1. This would result in the following scenario: course A is linked to quizzes 1, 2, and 3. Course B is linked to quizzes 4, 5, 6. Now, adding quiz 4 to course A results in quiz 4 being removed from course B because one quiz can't be in more than one course. Again, a notice would be given to the user, but no error message.

Taking this further, in a situation where the reference cardinality is less than unlimited, one might have a mechanism for preventing one node from "stealing" a reference from another node (a checkbox, perhaps). In this case, again taking the above example, editing course A and attempting to add quiz 4 would either generate an error message, or maybe quiz 4 wouldn't even be in the list of options of the drop-down menu, but instead in an explanatory text below: "quiz 4, quiz 5 and quiz 6 are not in the above because they are owned by another node".

Cheers,

Albert.

@alberto56 I think orphaning the nodes and removing there references is a step to far. Although I can see that it would perhaps in some cases be more user friendly than going to the other node release the reference and add it again.
The idea of showing which nodes can be referenced in dropdown could be done but what if you use the autocomplete widget?
For now, in the new version of the module I working on, I ll implement the solution which I had in mind which is the same as the one proposed in #8

This feature is included in 6.4 branches which is currently in development.
The new branch will add new features like automatic referencing (drush + batch api) and integration with other apis and modules that will make this module better integrate in the drupal machine.