I have entity as 'node' and entity_id as node ids. How to use this to show [node:title] field in Views?

You can't, is not supported yet.

I have the same problem, but with drupal 6, so I'm moving this issue to D6 because it seems to be a feature request for D7.
But for D6, with a version of views from a 6.x-3.x-dev version of March 2011, this relationship "Userpoints Transactions: Entity ID" worked well. When upgrading to the latest releases of views, it doesn't work anymore (and with the latest Userpoints 6.x-1.x-dev), so I'm also moving this to "bug report" (but maybe I shouldn't?)
It was very useful to extract information from the subject of a transaction, not only the title, this was really an awesome feature.

During my views update, I also noticed that some Content Taxonomy relationships weren't working anymore. This seems to have been fixed in a patch here : http://drupal.org/node/1316316#comment-5487702 , a one line patch.
=> Is there a way to replicate this patch for this relationship ?

Or maybe, as said in this issue http://drupal.org/node/1362658#comment-5487768 , the relationship "Userpoints Transactions: User" works well => Is there a way to replicate what has been done for this other relationship ?

Many thanks if you're taking the time to look at this issue.

Ok I tested the simplest solution and it worked, in userpoints.views.inc :

  $data['userpoints_txn']['entity_id'] = array(
........
    'relationship' => array(
      'base' => 'node',
      'base field' => 'nid', //------ replace 'field' by 'base field" here------//
      'label' => t('Entity'),
      'handler' => 'views_handler_relationship',
    ),
  );

With this all views using relationships based on entity IDs are working. Shouldn't this be committed ?

Berdir, I'm assuming in #1 you meant this relationship as generalized to entities. Is there a separate issue somewhere for generalizing to entities? I think 7.x-2.x might allow adding entity reference fields to the transaction, but for now I don't think I can link to anything other than a node and have it work in views, huh?

i tried the solution mention in #4 and it did work out...just patch it

Patch attached.

#8: userpoints-1335956-8.patch queued for re-testing.

What I meant in the other issue is that if you add a node relationship without also manually limiting entity_type to node, then it will also match for comment id's that have a node and so on. It would be great if the relationship handler could make sure that entity_type is node, which will probably require a custom relationship handler.

Also, this failed due to the old version, always use -dev.

#8: userpoints-1335956-8.patch queued for re-testing.

Thanks Berdir.

I thought the 'base' attribute was the table name. If that is the case, then the relationship would, in fact, be limited to nodes.

No, it won't be. It will be a "JOIN {node} n on n.nid = userpoints_transaction.entity_id". That will also match if entity_type is comment or user or anything else other than node, as long as entity_id has a corresponding node id.

Maybe a custom filter handler is an issue for Views if Entity API is active.

Thanks again. I cut my teeth on D5 and D6. D7 is still giving me culture shock, and as for D8... interesting mixture of anticipation and dread :-)

For the record, userpoints had the entity_type and id columns since 5.x, way before core was talking about an entity API :)

I know that views in core is doing something similar for #731724: Convert comment settings into a field to make them work with CMI and non-node entities for the comments table, looking at the patch there, it does define:

          'extra' => array(
            array(
              'field' => 'entity_type',
              'value' => 'node',
              'table' => 'comment'
           ),
          ),

So you could try something similar, just for our table and not comments. Then add a relationship in views and check that the join contains the type condition.

OK I see the curve you just threw at me. Back to my days as a conceptual modeller.

First, if the points are for a node, then nid identifies the node. It should not be filled if the points are for a comment (allow nid to be empty).

For comments, you should be using a cid field to point to the comment. The comment table will relate the comment to the node (not a comment, allow cid to be empty).

This will eliminate the ambiguity you see in nid. Rather than trying to distinguish meaning on the fly (functional interpretation), keep the meanings of the relationships distinct and static.

The data structure is there and works.

entity_type = 'node', entity_id = 5 => this references node with nid 5
entity_type = 'comment', entity_id = 5 => this references comment with cid 5.

All we need to do is making sure that the node reference, that points from entity_id to node.nid also enforces that entity_type is 'node' for these rows. And it looks like the default views relationship handler already has support for that, you just need to define the extra key in the definition as copied above, just need to change the table from comment to userpoints_txn.

Later, we could think about adding a relationship for every entity type that we have data for, but that's more complicated and we don't have to worry about that for now.

I understand that the base table for the query can be limited as follows:

$data['userpoints_txn']['entity_id'] = array(
      'title' => t('Entity ID'),
      'help' => t('The entity_id field. Used to relate to the node table.'),
      'extra' => array(
            array(
              'field' => 'entity_type',
              'value' => 'node',
      ),
      'field' => array(
          'handler' => 'views_handler_field',
      ),
      'argument' => array(
          'handler' => 'views_handler_argument_numeric',
          'numeric' => TRUE,
      ),
      'relationship' => array(
          'base' => 'node',
          'base field' => 'nid',
          'label' => t('Entity'),
          'handler' => 'views_handler_relationship',
      ),

However that would exclude any non-node records from the query, and you cannot redefine $data['userpoints_txn']['entity_id'] for the comments case to have both relationships. Putting an 'extra' in the relationship would not work as there is no 'entity_type' field in the node table. The limited query would no longer satisfy the use case requested by koron or the user I helped on Drupal Answers.

Although the simpler fix might not distinguish between 'node' and 'comment' points, the entity type could be returned by the query to make the results more specific, and displaying a node title (perhaps with link) would guide the user to the node to which the comment was attached.

I like the trend Drupal is showing, moving away from functional and towards conceptual database design, but until artifacts of the old ways, like the node and comments tables are eliminated, we are always going to see functional dependencies like this jump up and bite us.

BTW. Awesome module, and thank you to yourself and the other maintainers.

It's really not that complicated :)

- The entity_type is on the userpoints_txn table, it limits there. Everything on {node} is obviously a node.
- Excluding non-node matches is the whole point of this relationship. If you make it optional then it will still show the results for the other rows but e.g. no node title. And if you make it required, it will only show transactions related to nodes.
- You can define any number of "fields" in views data, it does not need to match to actual fields, you can use the 'real field' key to match it to the corresponding column or have a custom handler that knows how the column he wants is called.

I created the attached patch to demonstrate it:
- Removed the broken relationship column from entity_id
- Add a new node "field" that uses real field entity_id and consists only of a relationship to node with the entity type node extra condition.
- We can, as a follow-up think about how to add additional relationships for other entity types, we could just add a few hard coded ones, all entity types (could be a long list...), make it configurable... whatever, it will just be a loop/copy paste of the same definition.

I don't have any test data for 7.x-1.x at the moment, but the resulting query looks exactly like it should, good luck with testing :)

SELECT userpoints_txn.points AS userpoints_txn_points
FROM 
{userpoints_txn} userpoints_txn
LEFT JOIN {node} node_userpoints_txn ON userpoints_txn.entity_id = node_userpoints_txn.nid AND userpoints_txn.entity_type = 'node'
LIMIT 10 OFFSET 0

#21: views-node-relationship-1335956-20.patch queued for re-testing.

OK . I see the logic now. I have been all over D.O., and unsuccessful, looking for a developers manual or api reference which defines and gives examples of the various options. Thank you.

If you are looking at splitting out definitions for every entity_type, perhaps some sort of hook_alter might be in order to allow other modules to define and add their own relaionships.

Give me a couple of days to code & test, and I will do the patch for node and comment.

That hook is called hook_views_data_alter() :)

And as I said, my suggestion would be to get this in just for nodes, then forward port to 7.x-2.x (where we just need to define the relationship, everything else should be generated by entity.module) and then open a separate issue for other entity types. We could for example add a checkboxes list to the settings somewhere and allow to select which ones you want to have enabled, defaulting to node and comment.

I have tested your patch (#20), and it works well.

Thanks for testing, commited and pushed to 7.x-1.x

This needs a re-roll for 7.x-2.x.

Just cloned the git repo and this is not in the 7.x-1.x branch. What am I doing wrong ?

Looks like I forgot to push. Thanks for the reminder, it's there now!

- Added as a property to the transaction entity.
- Added getNode method.

I don't think that results in the right views data relationship? I assume we need to do that manually?

add info