- First commit to issue fork.
- @ericgsmith opened merge request.
- 🇳🇿New Zealand ericgsmith
Moved existing patch to MR.
I note that while this has been RTBC for almost 2 years there is mention in 📌 Refactor module architecture in a simpler, opinionated and more performant approach Needs review of removing views integration completely.
I have a use case that I am exploring using views to solve - and this patch gets me somewhat closer. Given this does a join from entity_usage to the entity its ignoring the vid - it would be good if we could either chose to join to the revision table instead of the base table, OR allow the relationship to have an additional config to add
'field' => $entity_type->getKey('revision'), 'left_field' => 'source_vid'
to the
relationship.extra
definition in order to only relate based on the default revision.
I'm more curious about the future of the views integration for this module - are further patches welcome or is the future for views integration a different module?
- 🇳🇿New Zealand ericgsmith
I have pushed an update to the MR with a change that allows specifying if the join should include the condition to match the source vid as well.
I appreciate this might over complicate it.
The original commit on the MR (552e2ea7452c5a3e42b78b952e573e1c8e55fe42) is what was RTBC'd in the past.
If this addition plugin just to add the join is over the top, perhaps we could either always add the condition or add 2 different relationships? I always get confused around the labels for default / current or however they are called.
I didn't want to highjack an issue that was previously RTBC, but since this has had so much timeout without being committed I think its worth disucssion this join criteria a bit more - and as above it would be good to know the future of views integration for this module.