The Vote entity extends ContentEntityBase, but ignores and re-implements many features already provided and implemented in ContentEntityBase. I alluded to this in #3150371: Vote/VoteInterface are documented improperly and incompletely
For example, ContentEntityBase defines base fields id, uuid, language, etc. which are common to ALL entities. Because Vote extends ContentEntityBase, Vote does not need to redefine these base fields, it just needs to properly delegate to the parent class. Because Vote is currently ignoring the parent class, we are duplicating code and losing functionality. Plus this duplicate code makes it harder to maintain - if a bug is fixed or a new feature added to the parent ContentEntityBase, that bug fix / new feature will NOT currently be inherited by Vote.
Here is a work in progress. The point of this patch is to invoke parent::baseFieldDefinitions() within Vote::baseFieldDefinitions so that the Vote entity will use the parent's implementation of the base fields. Right now Vote has a copy of those definitions from the parent rather than just inheriting them.
Note that this patch does not change any existing functionality of the Vote entity, but after the patch the Vote entity will have a few new base fields inherited from ContentEntityBase, so there will need to be a hook_update_N() to update the Vote entity on existing sites. That's why it's still a work in progress - everything but the update hook is complete.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 3153550-17-vote-entity.patch | 4.11 KB | tr |
Issue fork votingapi-3153550
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
tr commentedNote that #2898847: Vote list cache tag not invalidated when saving a vote is a related issue where again we aren't delegating to the parent, so we're losing functionality - cache tags aren't getting set properly.
Likewise, in #3153473: Making Votingapi Translatable, there is no need to completely redefine base fields etc. just to add language support, as language support will be inherited from the parent ContentEntityBase if we delegate the baseFieldDefinitions() to the parent properly.
Comment #3
tr commentedComment #4
tr commentedAdded related issue to link the core issue where ContentEntityBase acquired these base fields.
Comment #6
eelkeblokCorrect me if I'm wrong, but when comparing the old code to that of the ContentEntityBase, I don't think there are actually any database changes needed (for a while there, I though the type column needed to change to bundle, but there actually is a mapping in the annotation). Of course, this will need to be tested - I am currently waiting on a conversion script to turn ~330.000 flags into votes, I guess that should be sufficient - but I am just wondering if I am overlooking something.
Comment #7
tr commentedComment #17
tr commentedI screwed up the issue fork by trying to rebase the changes into 4.0.x. Maybe someone can fix that - I've tried all the simple things and am unwilling to spend more time on it.
So right now I will be relying on the patch instead. Here is a manual re-roll against 4.0.x.
Comment #19
tr commentedComment #20
guido_sComment #21
guido_sI just upgraded to 4.0.x-dev Version on a platform where I'm using this module with the Rate module with thumbsup rating and stars in entities (nodes and commerce products), views and webforms and had no issues so far without any database updates.
Upgrading drupal/votingapi (3.0.0-beta5 => dev-4.0.x 010514d)Would be nice to have a tagged release for security / stability reasons.
When I got @tr right in the D11 issues of this module, this issue here is the reason why there is no tagged D11 release yet.
But I don't see what isn't working and if there really is anything left that needs to be done for this.
Comment #22
guido_sEven with the patch from this issue I agree with @eelkeblok that it wouldn't require any db updates.
Also asked the AI: