From catch in #1805996: [META] Views in Drupal Core:
This isn't up-to-date with the core tracker schema which has some denormalization. Would be a critical performance regression if the tracker listing was updated to use it in its current state.
We were going to remove the view from the sandbox before the merge and re-add it (or at least I thought we were) but I discovered tonight when I tried to file a patch that it's still in there. So, we'll want to clean it up. We can probably do this when we convert the listing, but if not, the default view should be fixed or removed.
Comment | File | Size | Author |
---|---|---|---|
#13 | 1853572.13.patch | 15.93 KB | alexpott |
#9 | views-1853572-9.patch | 4.24 KB | xjm |
#3 | views-1853572-3.patch | 3.87 KB | xjm |
Comments
Comment #1
dawehnerSo the point catch is rising here is basically #1829734: Expose tracker data to views
I don't think there is a fundamental problem is using views for that, though it should perform.
Comment #2
xjmCool, postponing this on that then.
Comment #3
xjmActually, changing my mind; we'll want to completely rebuild the view, and we can do that when we convert it to core. So let's remove old, critically non-performant default view.
Comment #5
catch#3: views-1853572-3.patch queued for re-testing.
Comment #7
xjm#3: views-1853572-3.patch queued for re-testing.
Comment #9
xjmComment #10
aspilicious CreditAttribution: aspilicious commentedLets remove it!
Comment #11
dawehnerI would personally first get the tracker conversion in, see #1829734: Expose tracker data to views and then conver this view to it.
It seems to be, that people assume that a default view is actually used on the page. I really think this view is a good example of a non-trivial to configure view, so it should stay regardless whether it's usefull for an actual drupal site or not. Just for example you could use the some point when
dealing with the glossary view. Nearly noone really understands how to configure a glossary view out of the box, so having an example seems to be comparable with a good piece of documentation.
Comment #12
damiankloip CreditAttribution: damiankloip commentedLet's close this as a duplicate then and work in #1941830: Convert tracker listings to a view where we can create a new view. So the old one will get removed anyway.
Comment #13
alexpott#2080823: Create API to discover config entities' soft dependencies and use this to present a confirm form on module uninstall has exposed the fact that this is dependent on both the history and comment module to reliably manage this view we would need a new module.
The old patch does not apply.
Comment #14
dawehnerIt is a bit sad, though this seems to cause more troubles than wanted.
Comment #15
xjm+1 on committing this first and then restoring the functionality in #1941830: Convert tracker listings to a view when that lands (which can be whenever).
Comment #16
xjmI don't think the patch @alexpott just created needed a reroll in the same comment where he created it? :) Though we might have some tests for this view kicking around. We'll know in a bit I guess.
Comment #17
damiankloip CreditAttribution: damiankloip commentedNope, there are tests for tracker plugins, but not for this actual view. So tests confirm, and I confirm, we can just yoink this out.
Comment #18
catchCommitted/pushed to 8.x, thanks!