$base_table = $info->getBaseTable();
    if ($flag_type_def['entity_type'] == 'node') {
      $base_table = $info->getDataTable();
    }

Any entity might have a data table.

Ideally, we should have this logic taken care of by core: #2491687: Make EntityViewsData::getViewsTableForEntityType() public rather than protected.

In the meantime, we should fix this here anyway, and just use the data table if the entity type has one.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joachim’s picture

sumitmadan’s picture

Status: Active » Needs review
FileSize
580 bytes

Please review.

joachim’s picture

Status: Needs review » Needs work

Thanks!

Your change works, but we should be using EntityViewsData::getViewsTableForEntityType(), now that it's been made public. That has the same logic, and it means that should something change in Views, we're not affected.

Berdir’s picture

What if an entity type doesn't use an entity views data handler? :) The code should at least make sure to not fail then...

sumitmadan’s picture

By adding EntityViewsData::getViewsTableForEntityType() gives a warning because getViewsTableForEntityType() is not a static method.

Also a different issue While adding a flag it displays all the enity types in "Flag Type" field. While enabling it gives an error with following message :
The "contact_form" entity type did not specify a view_builder handler.

What if an entity type doesn't use an entity views data handler?

Does the above issue related to this comment or please suggest how can I check this?

Berdir’s picture

It's not meant to be static. You need to call it with $entity_type->getHandler('views_data') and check if it exists with hasHandlerClass()

joachim’s picture

> Also a different issue While adding a flag it displays all the enity types in "Flag Type" field. While enabling it gives an error with following message :
The "contact_form" entity type did not specify a view_builder handler.

Can you file a new issue for that please?

Though regarding contact_form entities, see #2409575: config entity types should not be flaggable.

sumitmadan’s picture

Status: Needs work » Needs review
FileSize
1.8 KB

I am not so good at object oriented programming. But still I have tried this and I am not sure if I correctly understood it.

Thoughts Please?

Status: Needs review » Needs work

The last submitted patch, 8: special_casing_for-2491879-8.patch, failed testing.

Berdir’s picture

+++ b/flag.views.inc
@@ -149,24 +150,23 @@ function flag_views_data_alter(array &$data) {
+    if($info->hasHandlerClass('views_data')) {
+      $base_table = EntityViewsData::getViewsTableForEntityType($info);

$info->getHandler('views_data')->getViewsTableForEntityType($info);

I'd also recommend to rename $info to $entity_type while touching the code, but I know that @joachim doesn't like even the smallest unrelated changes, so leaving that to him.

sumitmadan’s picture

Status: Needs work » Needs review
FileSize
2.19 KB

Thanks. :)

I have changed the name too.

@joachim Your thought on changing name?

joachim’s picture

Status: Needs review » Needs work

> but I know that @joachim doesn't like even the smallest unrelated changes, so leaving that to him.

You make me sound like a real nitpicker! :/

Let's go with the name change.

However, true to my reputation:

+++ b/flag.views.inc
@@ -145,28 +146,27 @@ function flag_views_data_alter(array &$data) {
+    if($entity_type->hasHandlerClass('views_data')) {

Needs a space between the if and the (.

If you can fix that, then I think this is good to go :)

sumitmadan’s picture

Status: Needs work » Needs review
FileSize
2.19 KB

Oops... My Bad!

joachim’s picture

Status: Needs review » Fixed

I totally failed to spot this line:

//use Drupal\views\EntityViewsData;

I've applied the patch and removed that before committing.

Thanks everyone :)

  • joachim committed 193e91d on 8.x-4.x authored by sumitmadan
    Issue #2491879 by sumitmadan: Fixed special casing for node data table...
sumitmadan’s picture

Again!!! My Bad!!! Sorry.

joachim’s picture

No problem! Happens to us all :)

Berdir’s picture

Sorry, didn't mean it in a bad way. I'm just usually a bit more relaxed with stuff like that but I didn't want to derail the issue with something that you'd prefer to happen separately.

joachim’s picture

Ha, ok :)
My first co-maintainer and mentor was sun, who tends to be quite strict about things like this (and coding standards too!), and I picked up the same habits :)

Working on a project like Flag, with a really long history, I've really learnt to appreciate the usefulness of keeping commits small and focussed. There have been lots of times when I've had to do git archaeology to try to figure out why a particular bit of code is there and what it's supposed to do, and unfortunately in Flag's history there are quite a few monster commits (including a horrendous 'dump everything from branch A to branch B' commit round about the start of the 6.x-2.x branch, which I always have to step over when using git blame!). So I'm trying to make the lives of future maintainers easier :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.