Reverse entity relationships for Views integration

(How) does this patch influence/interact with the following patch which enables reverse relationships in Views itself?
Http://drupal.org/node/1043260

Great idea!

-        return array(
+        $data += array(

This changes are confusing me, as still $data is written only once? So I don't think we need to do that.

   public function __construct($type) {
     $this->type = $type;
     $this->info = entity_get_info($type);
+    $this->relationships = array();
   }

Hm, so if the views data would be built multiple times on a page request, the controller would add in the same relationship multiple times? I've just moved that over to views_data().

I've tried to come up with an auto-generated help text for the reverse relationship and updated the patch. Patch works for me, however perhaps we should do something like entity_lcfirst() which works like lcfirst() in PHP 5.3? I miss drupal_lcfirst().

Correct patch.

Been testing this out as I need the reverse relation ship with something im doing with profile2.

Once applied the patch I keep getting.

Debug:
'Exception: SQLSTATE[23000]: Integrity constraint violation: 1052 Column \'uid\' in field list is ambiguous'
in views_plugin_query_default->execute() (line 1314 of /var/www-sites/drupal/dev/sites/all/modules/views/plugins/views_plugin_query_default.inc).

@sun yeah I need to give it another once over to figure out exactly what went wrong.. I created a patch for profile2 to do these views relationships there. Fargo pointed me here, so I removed my patched version of profile2 and patched entity API (dev) with this. Re configured my views flush all the caches and it kept spazzing out with that error, used fargo's patch.

I had to release with my patched version of profile2, but should have time 2m / Monday to get down and dirty with this as it's the way forward. So I'll get better feed back then..

Side note, strange that my watch list not have this issue in it.. Must be something changed since git down time.

As promised, retested this.

The reason I was getting

Debug:
'Exception: SQLSTATE[23000]: Integrity constraint violation: 1052 Column \'uid\' in field list is ambiguous'
in views_plugin_query_default->execute() (line 1314 of /var/www-sites/drupal/dev/sites/all/modules/views/plugins/views_plugin_query_default.inc).

Was due to the fact that I did not update the UID field in my out put of the view. It was still using the old relation ship from the patched version of my profile2.

All is good use this quite extensively building some hefty views, and its green lights all round. http://www.astuteresourcing.com/ currently has this patch applied and we use it for all the profile 2 entities we have defined.

Thanks, @sun and @fargo.

Sounds good. @sun: Does the patch in #7 work for you too?

Sorry but further testing my side im getting into this case

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 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 'LIKE 'applicant' ESCAPE '\\') ))) subquery' at line 5: SELECT COUNT(*) AS expression FROM (SELECT 1 AS expression FROM {profile} profile INNER JOIN {users} users_profile ON profile.uid = users_profile.uid INNER JOIN {flag_content} flag_content_users ON users_profile.uid = flag_content_users.content_id AND flag_content_users.fid = :views_join_condition_0 LEFT JOIN {field_data_field_applicant_first_name} field_data_field_applicant_first_name ON profile.pid = field_data_field_applicant_first_name.entity_id AND (field_data_field_applicant_first_name.entity_type = :views_join_condition_1 AND field_data_field_applicant_first_name.deleted = :views_join_condition_2) LEFT JOIN {field_data_field_applicant_last_name} field_data_field_applicant_last_name ON profile.pid = field_data_field_applicant_last_name.entity_id AND (field_data_field_applicant_last_name.entity_type = :views_join_condition_3 AND field_data_field_applicant_last_name.deleted = :views_join_condition_4) WHERE (( (.type LIKE :db_condition_placeholder_0 ESCAPE '\\') ))) subquery; Array ( [:db_condition_placeholder_0] => applicant [:views_join_condition_0] => 3 [:views_join_condition_1] => profile2 [:views_join_condition_2] => 0 [:views_join_condition_3] => profile2 [:views_join_condition_4] => 0 ) in views_plugin_pager->execute_count_query() (line 141 of /usr/www/users/astuten/sites/all/modules/views/plugins/views_plugin_pager.inc).

This is only happening when I add a field filter of profile2 type... looks like there is an escape char sneaking its way in.

Not sure if this is a views issue or ours, as it works in the preview. But as soon as I save the view it throws this.

Subscribe

Committed, thanks.

Not entire sure this is 100% fixed, still have problems with profile2. The page is a simple view (basetable, content) showing just a few fields of a news article, so nothing fancy. I'm sorry if I'm barking up the wrong tree, it might be a profile2 or views issue..

Setup:
Entity API 7.x-1.x-dev (2011-mar-22)
ctools 7.x-1.0-alpha4
profile2 7.x-1.0-beta2
Views 7.x-3.0-beta3

Debug:
'Exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column \'profile.pid\' in \'field list\''
in views_plugin_query_default->execute() (line 1354 of /drupal/sites/all/modules/views/plugins/views_plugin_query_default.inc).

Not really sure how this all works, but I'm guessing that profile2 build a new enity but some how this fail. I looked on the query generated by views

SELECT 
  node.title AS node_title, 
  node.nid AS nid, 
  node.language AS node_language, 
  node.created AS node_created, 
  profile.pid AS profile_pid, 
  'profile2' AS field_data_field_bilete_profile2_entity_type, 
  'node' AS field_data_field_ingress_node_entity_type
{node} node
WHERE (( (node.type IN  ('nyhende')) ))
LIMIT 20 OFFSET 0

Tried to run this manually against the db. and it is correct, this does not work, "profile.pid AS profile_pid"

>'Exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column \'profile.pid\' in \'field list\''

Sounds like your mysql table is missing the column. Anyway, please open new issues for any general views integration troubles.

subscribe

subscribing

Got the same SQL error as above;

Can we just add the column manually to fix the issue?

Subscribing

Subscribing

I am also getting this error trying to expose profile data in a view.

+++ views/entity.views.inc
@@ -98,6 +109,23 @@ class EntityDefaultViewsController {
+      $this->relationships[$info['base table']][$this->info['base table']] = array(
+        'title' => $this->info['label'],
+        'help' => t("Associated @label via the @label's @property.", array('@label' => $label_lowercase, '@property' => $property_label_lowercase)),
+        'relationship' => array(
+          'label' => $this->info['label'],
+          'handler' => 'views_handler_relationship',
+          'base' => $this->info['base table'],
+          'base field' => $views_field_name,
+          'relationship field' => isset($info['entity keys']['name']) ? $info['entity keys']['name'] : $info['entity keys']['id'],
+        ),
+      );

This isn't sufficient: if you have more than one entity property that links to another entity of the same type (i.e., same $info['base table']), you're overwriting any previously set relationships. $this->relationships needs to take the current field into account, and pass that information up to entity_views_data().

The fix is simple, but requires updating all views...

+1

ouch. People won't be happy with that, but we need to fix this. -> committed.

entity.views-relations-reversed.0.patch queued for re-testing.

Issue was fixed and committed, see #28!

ouch, #26 is going to break everyone's og views ... We should re-evaluate it.

Proposal: Keep the name of the first reverse-relationship to the old name, re-name all others.

ok, I've done so and committed it. See http://drupalcode.org/project/entity.git/commit/f0728d1

This means, user of the dev version might have to update their relationships *again* - sry for that. However, the majority of users which still uses the latest beta release won't get broken handlers that way.

OK, thanks for all your hard work. I think most people are going to be very thankful for a patch that do not break every view on their site :)