Hi all, Let's say I have two content types - a person and a bank account. A person can have several bank accounts, and a person also has an address. Now I need to present a listing if all the people who live in New Jersey and have more than $100k in their bank account. In any database application it would be dead easy - just use a SELECT.. JOIN on these two tables and you're done. However, on Drupal, I am not sure what is the best way to accomplish that. First thing I did was to define these two content types in CCK, install the relativity.module and declare parent-child relationships between the person and her bank account. Then I hit the wall.. I can't combine information in a view from these two content types, and I can't use views fusion module, as it doesn't know about relativity (only nodefamily). My dream solution would be to expose relativity.module into the views admin screens, and just add/filter the fields of the related content types. But since relativity is generic and views uses a flat view of all fields, I really can't think of a way to accomplish that cleanly. Of course I can write the query myself, but since these are CCK nodes, I can't use a direct SELECT, and have to iterate through the nodes manually. It is also not maintainable through the UI being strictly in code (and can't use views plugins etc.). Another option could be to use views hooks (pre_view, query_alter..) to load the parent node, check the condition and manipulate the view accordingly. This doesn't feel right neither. I ended up going back to my dream solution and face it with reality. Since I know my CCK structure and the queries I need, I can go specific. I created a module and added the 'location' table, but not connected to the 'node' table, rather to 'relativity' table, through the 'parent_nid'. This way I can add the parent-city as a field, filter and an argument to the view. As a bonus, I even reused the original location.module city argument handler. The downside is that it's quite a lot of code (although once written can be managed through the views administration). Does this make any sense? Isn't there a simpler solution? Cheers, -- Yuval Hager