Wildcard the 'members' join for "topic" data?

[(e) Eric]

I'm nearing the release of an app that will show some extra member variables in topics/messages/etc and I'm beginning to look at what will need to go into showing this data in the userinfopane. I noticed that all the data is coming from that 'members' join in topics.php, so I suppose I would need to edit that to include the new fields (since it would be impossible to use an action overloader to do it, unless I wanted to overwrite the entire thing), so I figured I'd ask... any chance that in a future version that join can simply use a wildard(*) instead of specific fields? I'm sure this won't be the last app to need to access custom fields in this deparment, and what with all the focus on hooks now and minimizing file edits, I figured this is a logical step.

Next step is to a solution to the missing link between template hook data and the template data it's hooking into... but I'll leave that for the already started threads about that issue. :)

[Mat Barrie]

Wildcard selects are generally frowned upon as they require additional resources for the server to handle (minimal, but still). What would probably be better is to not add custom fields to the members table, but rather to use the actual custom profile fields feature, as all custom profile fields are pulled into the select query in topic view (if I'm not mistaken)

[beeman]

The best way to allow more data to bee gathered would bee an addition to the hooks system so as well as action overloader, skin overloader and template hook you have query overloader, where you can either add to an existing query (add a select option, where or join) or compleatly overload it as the querys are already ran via a seperate class before being submitted to the database it shoulnt bee too hard to add the option.

However you would need access to all variables already loaded in the query.

[bfarber]

Challenging, for sure. On the one hand, as a modder I know where ibBookie is coming from. On the other hand, as a developer that works on IPS, Mat is absolutely right.

[KT Walrus]

I too have a need to add some filters to the topic view queries. I haven't looked into it yet since this is on my to-do list, but I would vote for some sort of query replacement/edit capability without modifying IPB source. Specifically, I'd like to see all queries labeled/numbered somehow and then an SQL hook that would feed the constructed query and the query label to the hook where it could be modified to add my extra where stuff or extra select columns just before executing it.