Active
Project:
Drupal core
Version:
main
Component:
views.module
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
23 Feb 2015 at 11:04 UTC
Updated:
28 Jun 2025 at 05:35 UTC
Jump to comment: Most recent
Problem/Motivation
The views data is coupled to the SQL schema. So once entity schema changes the views data change. We are automatically
adapting existing views, see #2341323: Adapt the references field / table names in views, when corresponding entity schema changes but we have no clue yet how we adapt existing code in FooViewsData.
Here is a small excerpt of NodeViewsData which would break in case nodes are not translatable anymore:
$data['node_field_data']['nid']['field']['id'] = 'node';
$data['node_field_data']['nid']['field']['argument'] = [
'id' => 'node_nid',
'name field' => 'title',
'numeric' => TRUE,
'validate type' => 'nid',
];
Proposed resolution
Expose the following variables to be used $this->viewsBaseTable; $this->viewsRevisionBaseTable; $this->entityBaseTable
Comments
Comment #1
xjmNot clear on the scope here -- is #2341323: Adapt the references field / table names in views, when corresponding entity schema changes regressing in Views? Or something else? (Trying to figure out if this should be an upgrade path issue and if it's critical.)
Comment #2
dawehnerTried to make the issue summary a bit more clear.
Comment #3
xjmSo let me know if this is correct: the consequences of not doing this are that any reference in code anywhere needs to be hand-patched for the updated table structure when an entity type changes its schema. And if they were not patched, any handlers or EntityViewsData implementations with those references would break. The views themselves would not be corrupt, because they got updated -- but they would not match the views integrations in code and would be broken when someone tried to use them, probably with query errors.
So the goal of this issue is to make it cleaner and less fragile to update existing code for those changes -- it's essentially a refactoring to make sure the code definition for the entity data model is defined in one place, rather than all over the place, and to reduce the ArrayPI leakage. Since there's a workaround (carefully patch every instance of references to the entity data), it makes sense for it to be major (not critical), and since the stored views themselves will still be correct, just not usable, it doesn't need an upgrade path. Does that all sound correct?
Comment #4
dawehnerWell, in case you just change the used handler, it will fallback to the default one, which probably should work,
but yes, in case you have defined an entirely new field for example, it might simply DIE.
Comment #5
dawehnerSo this issue is certainly unpostponed now.
Comment #19
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #20
xjmAs far as I know, this is still part of an important rearchitecture that would make Views more compatible with the entity system and the alternate storage backends. Reopening in my capacity as a Views subsystem maintainer.. @lendude can let us know where we're at on the overall goal of decoupling Views from the SQL schema.