Briefly, I know this sounds like a general query, which shouldn't be on this list. Two reasons,
1) This is for module integration, through the API.
2) Drupal core doesn't lean much towards trading with the Taxonomy, so we don't expect that of Views, either. We know we are wading in rather deep. Someone on the case could spare us trouble.
So, what are we up to? We've got our Views hooks up and running. We figured we wanted this query as a relationship. Views provides 'Parents' as a relationship, so 'Children' ties in with the developers, and also makes sense for a user.
We tried the dopey ('dopey' means we can account for it, but we don't know what happens out there in the functions or the context) approach,
$data['term_hierarchy']['tid'] = array(
'title' => t('Child terms'),
'help' => t('The child terms of the term.'),
'real field' => 'parent',
'relationship' => array(
'base' => 'term_data',
'field' => 'tid',
'label' => t('Children'),
),
);in a MODULE_views_data_alter() hook.
Came close, as it happens. UI looked good, here's the query,
SELECT term_data.tid AS tid,
term_data.name AS term_data_name,
term_data.vid AS term_data_vid,
term_data.description AS term_data_description
FROM term_data term_data
LEFT JOIN term_hierarchy term_hierarchy ON term_data.tid = term_hierarchy.tid
LEFT JOIN term_data term_data_term_hierarchy ON term_hierarchy.tid = term_data_term_hierarchy.tid
WHERE term_data_term_hierarchy.tid = 0but 'real field' doesn't seem to have grabbed us a 'parent' field reference. 'field' was no different. A trace suggested Views knew what we were up to, but was overriding.
An attempt to alias throughout...
$data['term_children']['child_terms'] = array(
'group' => t('Taxonomy'),
'table'=> 'term_hierarchy',
'real field' => 'parent',
'title' => t('Child terms'),
'help' => t('The child terms of the term.'),
'relationship' => array(
'base' => 'term_data',
'field' => 'tid',
'label' => t('Children'),
),
);...vanished from the UI?
Is this tid field override happening because we're working in the context of a base table so referenced? So could we alias the base table? Or can we use an aliased join? How would we get that info into a relationship?
Or are we barking up the wrong tree? Do we have to write our own relationship handler? Views seems to use the same one throughout (any models for us to work from)?
Or is there some way through using arguments or filters, despite the UI discrepancy (minds wandering)?
Help much appreciated,
Rob
Comments
Sorry, I should have mentioned...
We only need the immediate child terms of any provided term. Depth +1.
(folks tend to think in terms of recovering all relevant nodes below, which is such a useful shopping/library experience, so I really should have made this clear)
Nearly there
Yes, though it may involve a patch. Thanks to anyone who has considered the problem (you can still post if you like!).
Situation resolved
Shouldn't try brainy coding after work...
Please post solution. Views
Please post solution. Views isn't picking up my "real field" key either.
"relationship field"
Apparently you can use a key 'relationship field' within the relationship definition.